General problem explanation
System.currentTimeMillis represents a wall-clock time and therefore is not monotonic, i.e., it is allowed to go backwards: return t1 and after that (in the happens-before order) return t2 < t1. While the lack of monotonicity is not explicitly expressed in the method specification, the fact that it returns wall-clock time and one can set machine time to a past instant (NTP implementations may also do that) implies the lack of monotonicity. As a result, naive attempts to calculate, e.g. timeout expiration, may fail: the expression (currentTime = System.currentTimeMillis()) - startTime > timeout, where timeout is 1000 ms may evaluate to false for about an hour if the machine time is shifted back 1 hour, which misses the timeout for no good reason.
System.nanoTime on the other hand does not represent a wall-clock time (this is explicitly expressed in the specification) and is explicitly allowed to be used for measuring elapsed time.
The Go standard library tries to prevent users from using a non-monotonic timer when measuring elapsed time by hiding both timers behind a single API: https://golang.org/pkg/time/#hdr-Monotonic_Clocks.
Specific problem
Relevant places in the codebase
Proposed solution
UsageTrackingInternalConnection does not need to track wall-clock time in openedAt/lastUsedAt. We can and should use System.nanoTime to detect if maxConnectionIdleTimeMS/maxConnectionLifeTimeMS is exceeded.
|