[ http://jira.activemq.org/jira//browse/AMQ-643?page=comments#action_35847 ]
Kevin Yaussy commented on AMQ-643: ---------------------------------- So, in the case of the client setting the maxInactivityDuration value on its connector url, you are saying that the broker must have a maxInactivityDuration setting (with the same value) on the transportConnector url? Not quite sure why you would want to make this restriction. Seems problematic with regards to potential timing issues. Also, if you set the maxInactivityDuration on the transportConnector url, then when you have two brokers connected to each other, they continuously drop connections and resubscribe. If you also set maxInactivityDuration on the networkConnector url for each broker, then the brokers still drop connections and get whacked out with subcriptions. I'll attach broker XML configs in a bit. > maxInactivityDuration does not seem to work properly > ---------------------------------------------------- > > Key: AMQ-643 > URL: http://jira.activemq.org/jira//browse/AMQ-643 > Project: ActiveMQ > Type: Bug > 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 RC1 > > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
