You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Chris Hofstaedter <ch...@nmwco.com> on 2007/01/05 15:17:35 UTC
Race Condition can result in hang on remoteBrokerNameKnownLatch
My environment is comprised of Windows XP, AMQ v4.0.2, demand
forwarding, failover = true, client and broker are all within the same
VM. Typically, my client and broker would not be within the same VM,
but this issue was encountered while executing my junit tests - not in a
typical deployment environment.
Basically, DemandForwardingBridgeSupport.startLocalBridge() hangs on
remoteBrokerNameKnownLatch.await();
It looks like the broker name becomes known prior to the call to await.
I think the response is coming in after the triggerLocalStartBridge
thread is spawned and the synchronized block in
DemandForwardingBridgeSupport.startRemoteBridge() is exited but before
the await call in triggerLocalStartBridge.
Like I said, I've only run into this when running demand forwarding with
client and broker in the same VM along with a high volume of messages
sent immediately after the connection is established, which for me, is
an artifact of junit testing.
I have a relatively small number of clients that should connect fairly
infrequently, so I just put a bandaid of a 100ms wait into
TcpTransportServer.run right before getAcceptListener().onAccept() which
allows my tests to complete successfully and has no appreciable impact
on the performance I care about but it's obviously not a valid fix for
the race condition.
RE: Race Condition can result in hang on remoteBrokerNameKnownLatch
Posted by Chris Hofstaedter <ch...@nmwco.com>.
Created AMQ-1120
-----Original Message-----
From: Chris Hofstaedter [mailto:chrish@nmwco.com]
Sent: Friday, January 05, 2007 9:18 AM
To: activemq-users@geronimo.apache.org
Subject: Race Condition can result in hang on remoteBrokerNameKnownLatch
My environment is comprised of Windows XP, AMQ v4.0.2, demand
forwarding, failover = true, client and broker are all within the same
VM. Typically, my client and broker would not be within the same VM,
but this issue was encountered while executing my junit tests - not in a
typical deployment environment.
Basically, DemandForwardingBridgeSupport.startLocalBridge() hangs on
remoteBrokerNameKnownLatch.await();
It looks like the broker name becomes known prior to the call to await.
I think the response is coming in after the triggerLocalStartBridge
thread is spawned and the synchronized block in
DemandForwardingBridgeSupport.startRemoteBridge() is exited but before
the await call in triggerLocalStartBridge.
Like I said, I've only run into this when running demand forwarding with
client and broker in the same VM along with a high volume of messages
sent immediately after the connection is established, which for me, is
an artifact of junit testing.
I have a relatively small number of clients that should connect fairly
infrequently, so I just put a bandaid of a 100ms wait into
TcpTransportServer.run right before getAcceptListener().onAccept() which
allows my tests to complete successfully and has no appreciable impact
on the performance I care about but it's obviously not a valid fix for
the race condition.