[
https://issues.apache.org/jira/browse/AMQ-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13866479#comment-13866479
]
Anuj Khandelwal commented on AMQ-4955:
--------------------------------------
Hey,
I am facing the similar issue in which I can see lot of connections from the
same client ( around 100). I think connections are not getting closed properly.
Configuration:
1. All clients are using pooled connection factory where max Connection limit
is specified as 3.
2. ActiveMQ version: 5.8
I suspect that default value of 'maxInactivityDuration' is less (30 sec) and
broker might not able to send/read heartbeats for all the connections in this
given specified time. So I think by increasing the value of
'maxInactivityDuration' we could avoid this issue since broker will have enough
time to handle heartbeat related stuff.
I think Tim might help us here.
Thanks,
Anuj
> 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)
