On Fri, 23 Nov 2018 at 14:01, Sami Siitonen <[email protected]> wrote:
> 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. > Yeah - sorry that's the part I picked up upon... the actual report "Changing system time causes [...] drop[ped] connections" is entirely accurate... I think it's just a bit use-case dependent as to whether this is a bug or "feature" (e.g. if you paused a VM for 5 seconds and then resumed it, then using wall-clock time would mean that the next heartbeat would be more likely to be sent at the correct time (to a client on a different machine), whereas system time may cause a client to assume the broker is dead and disconnect because the broker waited an extra 5 seconds to send a heartbeat). > 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 > > Yeah - again it very much depends on the use case. In your use case I can see that this is "buggy" behaviour. > 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? > > Not really. Honestly, I find the value of heartbeating somewhat dubious, especially if client and broker are on the same machine. At that point the only error condition you are catching is that the client (or broker) has got stuck in some condition where it is "hung" but has not closed the TCP connection. I'll look at doing a change to moving to nanoTime, but it's the sort of think that is likely to generate subtle bugs (point in time millis since epoch, point in time nanos, and elapsed millis will all use "long" as the datatype, so there's a higher chance of messing something up). -- Rob > -- > 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] > >
