Re: ActiveMQ 5.5.1 - Connections stuck in CLOSE_WAIT state, reaching file descriptor limit

2014-01-23 Thread David O'C
As mentioned before, the broker wasn't at the maximum heap limit. The heapdump was manually created using jmap but by using the -F option as ActiveMQ wouldn't accept even JMX connections. -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-5-5-1-Connections-stuck-

Re: ActiveMQ 5.5.1 - Connections stuck in CLOSE_WAIT state, reaching file descriptor limit

2014-01-22 Thread David O'C
The broker wasn't at its memory limit at the time when this had occurred, but it wouldn't allow for JMX connections. I'd assume I was able to collect a heapdump before ActiveMQ was restarted and it does mention the Server Transport thread mentioned earlier. I'm not able to identify the thread to

Re: ActiveMQ 5.5.1 - Connections stuck in CLOSE_WAIT state, reaching file descriptor limit

2014-01-21 Thread David O'C
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 This had to be taken with force with jstack as ActiveMQ at that stage would not ac

ActiveMQ - 5.5.1, connections stuck at CLOSE_WAIT, reaching file descriptor limit

2013-09-22 Thread David O'C
Hi, I have seen an issue seen where ActiveMQ 5.5.1 would keep outbound connections in a CLOSE_WAIT state, to the point where the application reaches the file descriptor limit. The broker uses the Openwire format on TCP with closeAsync set to false. It is also non-persistant, storing all messages