The connection timeouts are defined by the AMQP protocol and, since in general the two ends of the connection would be on different machines, implicitly refer to externally observable time (to the extent that such a concept is meaningful).
You are changing the literal system time in your system, not just having it update for daylight saving. Daylight saving does not change "number of elapsed milliseconds since the epoch". Unless your system is suffering really dreadful drift, regular updates via NTP will not adversely affect the timeout processing, as the magnitude of any NTP updates should be small (and connection timeout thresholds should be (relatively) large - certainly in the order of multiple seconds, not milliseconds). Admittedly there is a case to be made to switch to System.nanoTime since it wouldn't be affected by updates to the system time, but then if the updates are being done by NTP, and your system is so poor at accurate time measuring that that is making significant updates, it is probably breaking the AMQP contract for timeouts to use the inaccurate timekeeping of your machine. Changing the system time is effectively changing "reality" and I'm not sure that there is a right or wrong approach here - if you see a lot of drift and significant updates from NTP I'd just use longer connection timeouts, or turn them off completely if you want to suspend VMs. If the broker were dropping connections due to daylight saving times changes that would definitely be a bug - and I'm pretty confident that on a correctly set up machine it won't happen... dropping due to changing the system time is much less clear to me -- Rob On Fri, 23 Nov 2018 at 10:32, Sami Siitonen <[email protected]> wrote: > I verified that system.currentTimeMillis returns walltime instead of > monotonic time so it cannot be used to calculate timeouts. > The problem here concerns every situation where walltime has shifted > somehow > and adjusted back, for example when system clock is somehow drifted enough > and NTP is used to adjust the clock. > I did a short test program: > > import java.text.DateFormat; > import java.text.SimpleDateFormat; > import java.util.Date; > import java.io.Console; > import java.io.IOException; > import java.lang.*; > > public class JavaTimeTest > { > public static void main(String[] args) > { > DateFormat dateFormat = new SimpleDateFormat("dd.MM.yyyy > HH:mm:ss"); > > long currentTimeBefore = System.currentTimeMillis(); > System.out.println("Current time is now: " + currentTimeBefore + > "ms"); > System.out.println("As DateTime it is: " + > dateFormat.format(currentTimeBefore)); > > System.out.println("Change time and press enter to continue..."); > try > { > System.in.read(); > } > catch (IOException e) > { > e.printStackTrace(); > } > > long currentTimeAfter = System.currentTimeMillis(); > System.out.println("Current time is now: " + currentTimeAfter + > "ms"); > System.out.println("As DateTime it is: " + > dateFormat.format(currentTimeAfter)); > > long timeDiff = currentTimeAfter - currentTimeBefore; > System.out.println("Difference is: " + timeDiff + "ms"); > } > } > > .. and the printout looks like this when I manually change system time a > day > forward: > > Current time is now: 1542964907800ms > As DateTime it is: 23.11.2018 11:21:47 > Change time and press enter to continue... > > (...at this point I changed system time manually...) > > Current time is now: 1543051313048ms > As DateTime it is: 24.11.2018 11:21:53 > Difference is: 86405248ms > > I hope this clarifies the problem. > > -- > Sami > > > > > -- > Sent from: > http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
