Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Date: Sat, 30 Aug 2014 20:19:23 -0700 (PDT)
From: artnaseef <art@artnaseef.com>
To: users@activemq.apache.org
Message-ID: <1409455163574-4685180.post@n4.nabble.com>
In-Reply-To: 
 <CAKWiyj04=yR9qiMxj8U2CgDK-wOS3ATProAd6v7sEeT94ib=tg@mail.gmail.com>
References: <1408643799623-4684887.post@n4.nabble.com>
 <1408768871288-4684969.post@n4.nabble.com>
 <CAKWiyj04=yR9qiMxj8U2CgDK-wOS3ATProAd6v7sEeT94ib=tg@mail.gmail.com>
Subject: Re: JMS to JMS bridge reconnection dispatching not working in
 simple conditions
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.