You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Yuriy Sidelnikov (JIRA)" <ji...@apache.org> on 2013/05/29 11:31:21 UTC

[jira] [Updated] (AMQ-4561) Deadlock in DemandForwardingBridgeSupport class if ConsumerInfo message has arrived before BrokerInfo message.

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

Yuriy Sidelnikov updated AMQ-4561:
----------------------------------

    Description: 
To establish connection a spoke broker sends some special messages to the hub:
•	BrokerInfo
•	ConnectionInfo
•	SessionInfo
•	ProducerInfo
•	ConsumerInfo
In return hub gsends exactly the same set of messages:
•	BrokerInfo
•	ConnectionInfo
•	SessionInfo
•	ProducerInfo
•	ConsumerInfo
 
All messages are sent asynchronously so message order is not guaranteed. 
 
However BrokerInfo message has to be delivered BEFORE ConsumerInfo message to the spoke broker because:
1. ConsumerInfo processing logic is depended on some information provided in BrokerInfo message so spoke broker side has lock on it.
2.  All incoming messages are processed in the same thread including reading from tcp/nio stream.
Short excerpt from DemandForwardingBridgeSupport class:
private void startLocalBridge() throws Throwable {   BrokerInfo message processing
…..
    localStartedLatch.countDown();
            }
And ConsumerInfo message processing part has the lock:
case ConsumerInfo.DATA_STRUCTURE_TYPE:
                                localStartedLatch.await();
So if ConsumerInfo message has been received before BrokerInfo message the consuming thread will be in dead lock: 
Name: ActiveMQ NIO Worker 13
State: WAITING on java.util.concurrent.CountDownLatch$Sync@150b06b
Total blocked: 1  Total waited: 3
Stack trace: 
 sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:534)


  was:
To establish connection a spoke broker sends some special messages to the hub:
•	BrokerInfo
•	ConnectionInfo
•	SessionInfo
•	ProducerInfo
•	ConsumerInfo
In return hub sends exactly the same set of messages:
•	BrokerInfo
•	ConnectionInfo
•	SessionInfo
•	ProducerInfo
•	ConsumerInfo
 
All messages are sent asynchronously so message order is not guaranteed. 
 
However BrokerInfo message has to be delivered BEFORE ConsumerInfo message to the spoke broker because:
1. ConsumerInfo processing logic is depended on some information provided in BrokerInfo message so spoke broker side has lock on it.
2.  All incoming messages are processed in the same thread including reading from tcp/nio stream.
Short excerpt from DemandForwardingBridgeSupport class:
private void startLocalBridge() throws Throwable {   BrokerInfo message processing
…..
    localStartedLatch.countDown();
            }
And ConsumerInfo message processing part has the lock:
case ConsumerInfo.DATA_STRUCTURE_TYPE:
                                localStartedLatch.await();
So if ConsumerInfo message has been received before BrokerInfo message the consuming thread will be in dead lock: 
Name: ActiveMQ NIO Worker 13
State: WAITING on java.util.concurrent.CountDownLatch$Sync@150b06b
Total blocked: 1  Total waited: 3
Stack trace: 
 sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:534)


    
> Deadlock in DemandForwardingBridgeSupport class if ConsumerInfo message has arrived before BrokerInfo message.
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-4561
>                 URL: https://issues.apache.org/jira/browse/AMQ-4561
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.6.0, 5.7.0
>            Reporter: Yuriy Sidelnikov
>              Labels: broker, deadlock
>
> To establish connection a spoke broker sends some special messages to the hub:
> •	BrokerInfo
> •	ConnectionInfo
> •	SessionInfo
> •	ProducerInfo
> •	ConsumerInfo
> In return hub gsends exactly the same set of messages:
> •	BrokerInfo
> •	ConnectionInfo
> •	SessionInfo
> •	ProducerInfo
> •	ConsumerInfo
>  
> All messages are sent asynchronously so message order is not guaranteed. 
>  
> However BrokerInfo message has to be delivered BEFORE ConsumerInfo message to the spoke broker because:
> 1. ConsumerInfo processing logic is depended on some information provided in BrokerInfo message so spoke broker side has lock on it.
> 2.  All incoming messages are processed in the same thread including reading from tcp/nio stream.
> Short excerpt from DemandForwardingBridgeSupport class:
> private void startLocalBridge() throws Throwable {   BrokerInfo message processing
> …..
>     localStartedLatch.countDown();
>             }
> And ConsumerInfo message processing part has the lock:
> case ConsumerInfo.DATA_STRUCTURE_TYPE:
>                                 localStartedLatch.await();
> So if ConsumerInfo message has been received before BrokerInfo message the consuming thread will be in dead lock: 
> Name: ActiveMQ NIO Worker 13
> State: WAITING on java.util.concurrent.CountDownLatch$Sync@150b06b
> Total blocked: 1  Total waited: 3
> Stack trace: 
>  sun.misc.Unsafe.park(Native Method)
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
> java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:534)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira