How about a stack trace on the client? Can you look for the consumer threads and see what they are doing?
Note that with producers and consumers on the same connection, it's possible to reach a deadlock if producer-flow-control kicks in because the entire connection is blocked, not just the one producer. There are two ways this can happen. First, if the client produces and consumes the same destination. Second, if the client is producing one destination and consuming a second destination and another client is consuming the first and producing to the second. Actually, more complicated possibilities exist as well. Your best bet is to never consume and produce on the same connection so that consumption never blocks due to producer-flow-control. In that scenario, deadlocks won't happen because consumers can always consume. Back to stack traces - if the consuming threads are blocked waiting to obtain a lock while producing threads hold that lock, that could indicate the problem. Anyway, slow consumption is quite often the cause of broker hangs, so looking for slow consumption and understanding speeding consumption (or slowing production) is important. If the broker JVM becomes completely unresponsive, try connecting jconsole or visualvm before the broker hangs and then watch memory. If the JVM is running out of Heap or Permgen space, that would explain the hung broker. -- View this message in context: http://activemq.2283324.n4.nabble.com/Broker-Hangs-after-some-time-or-does-nothing-tp4677506p4677656.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
