[
https://issues.apache.org/jira/browse/AMQ-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13863116#comment-13863116
]
Murali Mogalayapalli commented on AMQ-4955:
-------------------------------------------
1. When the server starts a transport connection, the first command it is
dispatching is BrokerInfo command
Note: BrokerInfo command is not tagged as DispatchMessage ( isMessageDispatch()
is false on Broker Command)
2. WireFormatNegotiator::oneway method throws a IOException with Wire format
negotiation timeout
3. TransportConnection::processDispatch method ignores that IOException because
the command that was sent out is not a MessageDispatch Command.
Result is Wire format negotiation timeout is thrown out without being handled
resulting the ActiveMQ Transport thread leak
I have fixed this by added the following lines of code to the
TransportConnection:processDispatch 's IOException handling block of code.
if(command.isBrokerInfo())
throw e;
> 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
> Priority: Critical
> Attachments: 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.1.5#6160)
