I think it should cause the connection to die. The subs currently don't deal with a dispatch failure wrt stats and redelivery so the only safe thing to do is termination. On 1 Apr 2014 06:28, "Arthur Naseef (JIRA)" <[email protected]> wrote:
> > [ > https://issues.apache.org/jira/browse/AMQ-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13956124#comment-13956124] > > Arthur Naseef commented on AMQ-4955: > ------------------------------------ > > Reading back through the comments, I see the issue being raised now -- the > eaten IOException for all commands except MessageDispatch. > > I think the right thing to do here is to always re-throw the exception. > Can anyone think of a case in which an IOException on > Broker.preProcessDispatch() or TransportConnection.dispatch() could have a > non-fatal meaning? > > > TCP Connections and related thread leak. > > ---------------------------------------- > > > > Key: AMQ-4955 > > URL: https://issues.apache.org/jira/browse/AMQ-4955 > > Project: ActiveMQ > > Issue Type: Bug > > Components: Broker > > Affects Versions: 5.8.0 > > Environment: Windows 2008 R2, Jdk 1.7.40 > > Reporter: Murali Mogalayapalli > > Assignee: Arthur Naseef > > Attachments: AMQ4955Test.java, TCP-Connection.jpg, > ThreadStack.jpg, activemq.xml > > > > > > TCP Connections and related thread leak. > > Scenario > > Active MQ version 5.8 > > NMS Client version 1.6 > > OS - Windows 2008 R2 > > JDK - 1.7.x > > activemq.xml is attached > > If a client connectivity gets lost between the time the initial socket > is created and the exchange of the wire format, the active MQ server's > Client's server thread gets blocked in socket read hanging out the TCP > connection and the related thread > > Here are the steps to recreate > > 1. Configure the Active MQ server with the activemq.xml attached. > > 2. Start the client in a debugger and have a break point at a place in > such a way that the client can be disconnected after the socket is > established. > > 3. Once the breakpoint is hit, disconnect the client machine from the > network > > 4. Kill the client- This basically simulates a situation where the > socket tear down packets are not reached the active mq server. > > 5. Open the JConsole. Look for the hanging TCP connection and the > related thread. > > Is there an configurable option in Active MQ to sweep and close the > connections, on regular interval, that still didn't finish the wire > protocol negotiation? > > > > -- > This message was sent by Atlassian JIRA > (v6.2#6252) >
