activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Hendley <Sam.Hend...@sensus.com>
Subject RE: Faster detection of failure on network connections in "cable pull" scenario
Date Tue, 17 Mar 2015 13:23:17 GMT
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.

Mime
View raw message