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 http://activemq.apache.org/activemq-inactivitymonitor.html 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? Tim On Tue, Mar 17, 2015 at 7:23 AM, Sam Hendley <sam.hend...@sensus.com> 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: > http://activemq.2283324.n4.nabble.com/Faster-detection-of-failure-on-network-connections-in-cable-pull-scenario-tp4691835p4693362.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
