Good catch. Something looks very wrong with this deadlock picture. Both
threads are blocking on this call:
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:66)
Which is this instruction:
writeLock.lock();
Which is this method call:
java.util.concurrent.locks.ReentrantLock.lock();
Either one or the other should hold the lock if it's truly a deadlock, which
leads to the question of why they both block attempting to lock it. Can you
upload the full stacktrace? If you need a place, it would be appropriate to
create a ticket and attach it there.
Further, since "ActiveMQ Transport: tcp://localhost/127.0.0.1:61618@55559"
calls MutexTransport.oneway() twice in the same stack trace, it must be the
thread already holding the lock - so, why would it block waiting to lock it
again? The ReentrantLock allows multiple, recursive locks by the same
thread.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/JMS-to-JMS-bridge-reconnection-dispatching-not-working-in-simple-conditions-tp4684887p4685180.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
