I have seen something like this when the hand off thread that deals with accepted sockets die. The error handling needs to be improved to make that case more obvious. It is a long shot, but you could disable the use of an accept queue and see if that resolves the problem.
<transportConnector name="openwire" uri="<host>:<port>?useQueueForAccept=false"/> The thread name (from trunk) that handles accepted sockets server side is prefixed with "ActiveMQ Transport Server Thread Handler:" so if that is not visible, which seems to be the case in a cursory look at the jstack, you could be in business. useQueueForAccept=true allows the broker to handle a connection storm without a tcp timeout, however clients typically retry so it is not a big deal if it is set to false. On 21 January 2014 19:50, David O'C <mrdavi...@gmail.com> wrote: > Hi Christian, > > Apologies for the late reply. I've a thread dump of the broker when it had > reached the limit for open sockets. > > actmqjstack.txt > <http://activemq.2283324.n4.nabble.com/file/n4676596/actmqjstack.txt> > > This had to be taken with force with jstack as ActiveMQ at that stage would > not accept any JMX connections. > > Regards, > David > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/ActiveMQ-5-5-1-Connections-stuck-in-CLOSE-WAIT-state-reaching-file-descriptor-limit-tp4671744p4676596.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. -- http://redhat.com http://blog.garytully.com
