activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: Faster detection of failure on network connections in "cable pull" scenario
Date Sun, 26 Apr 2015 15:50:22 GMT
I would have thought that there would be keepalives sent in both directions
on any connection irrespective of whether it's used for sending or
receiving message, and that the lack of receipt of them on that connection
would have declared it dead.  If the former is true, then there's a bug in
the detection algorithm (and a missing unit test!); if the former isn't
true, then I'd ask why not (and why the wiki page at is so
misleading/inaccurate) and propose that we implement it that way.  Handling
this directly with the inactivity monitor sounds better than the checks you
proposed, since it falls more cleanly into the paradigms ActiveMQ is
already using.

Can you test whether keepalives are being sent to the producer side of your
connection while the network cable is connected, so we know which of the
two scenarios I described above is the accurate one?


On Tue, Mar 17, 2015 at 7:23 AM, Sam Hendley <> wrote:

> We have been trying to run with the "small socketBuffer" strategy but this
> hasn't been as successful as I was hoping. Apparently the socketBuffer size
> we are attempting to configure is more of a suggestion than a absolute
> setting. Even when I configure it down to 2048 or 1024 linux will actually
> allow the socket buffer to contain up to 12k data before blocking any
> writes. Since my packets are small and my clients throttle it can take
> minutes before I have generated that much data to cause the socket write to
> actually block long enough to trigger the WriteTimeoutFilter.
> I have been looking over the activemq source code and think the behavior
> could be adjusted to react faster to this problem. Using
> DemandForwardingBridge as my example I think we could instrument the
> enqueueCounter and dequeueCounter to look for an inactivity gap of larger
> than X seconds between an enqueue and any dequeue.
> Basically I think the logic needs to be:
> * On Dequeue, check if enqueue count is > 0, set the timeout to now, if 0
> clear timeout
> * On Enqueue, check if timeout is set, if timeout > max break connection,
> if
> not set, set to current time
> It's not clear to me if this would fit in any of the current Abstractions.
> In the Demand forwarding bridge this looks like it might only work if
> asyncSend was set = true?
> I am open to other suggestions, this is our last big issue in our HA
> testing
> so I am eager and willing to try other alternatives.
> Thanks again,
> Sam Hendley
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message