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.
