Hi, Sorry about the DST, I didn't verify that part of the problem myself when I got this thing to solve and included it as a (bad) example so it probably doesn't cause any erratic behaviour in J-Broker. My problem more specifically manifests itself in a server pair where time (among other things) is synced between these two servers. The network connection between those servers might be down for a long time and time might jump back or forth more than the value of timeout at the moment when connection is re-established or at least we should take that into account by some other way than setting timeout value to some arbitrary big number. The broker and clients runs only locally in both servers, luckily no communication between servers. Basically I cannot guarantee that the system time will not jump around because of these syncs, it might even jump back to past. It sounds an interesting solution if walltime is used to determine if a timeout occurred or not because knowledge of the absolute time should be irrelevant, only difference between two events should matter. This kind of behavior was considered as a bug in C++ QPID and resolved couple of years ago: https://bugzilla.redhat.com/show_bug.cgi?id=1080165
So you mentioned that switch to System.nanoTime is planned. In the meanwhile is there any better way to work this around than disabling heartbeating altogether? -- 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]
