Race Condition can result in hang on remoteBrokerNameKnownLatch
---------------------------------------------------------------
Key: AMQ-1120
URL: https://issues.apache.org/activemq/browse/AMQ-1120
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 4.0.2, 4.0.1, 4.0
Environment: Windows XP, demand forwarding, failover == true
Reporter: Chris Hofstaedter
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
