activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Davies (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (AMQ-1120) Race Condition can result in hang on remoteBrokerNameKnownLatch
Date Wed, 09 Apr 2008 18:39:32 GMT

     [ https://issues.apache.org/activemq/browse/AMQ-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rob Davies reassigned AMQ-1120:
-------------------------------

    Assignee: Rob Davies

> 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, 4.0.1, 4.0.2
>         Environment: Windows XP, demand forwarding, failover == true
>            Reporter: Chris Hofstaedter
>            Assignee: Rob Davies
>             Fix For: 5.1.0
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message