Kevin Yaussy commented on AMQ-643:
Tried this out yesterday and it seems to work perfectly. I was able to freeze brokers and have them disconnect from each other, but recover after unfreezing. Same for clients.
Nondurable messages are still queued to a disconnected broker, but that can be mitigated by having the asyncDispatch and an eviction strategy to your liking. I'd rather see the subscriptions dropped, and no further queuing, but maybe that wasn't doable.
> Components: Connector
> Versions: 4.0 RC1
> Environment: AMQ 4 03/17/2006 SNAPSHOT
> Solaris 8, 10
> Reporter: Kevin Yaussy
> Assignee: Hiram Chirino
> Fix For: 4.0 RC 2
> Attachments: amq1.xml, amq2.xml
> AMQ 4 03/17/2006 SNAPSHOT
> Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection.
> Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck.
> I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway.
> However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen:
> 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place.
> 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again.