activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Hofstaedter" <chr...@nmwco.com>
Subject RE: Race Condition can result in hang on remoteBrokerNameKnownLatch
Date Fri, 05 Jan 2007 14:51:03 GMT
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.
 
 

Mime
View raw message