Hi： We ran into this dead lock since upgrade to 5.11.1. In short, this dead lock happens on network connector when "duplex" is set to "true". For details of replicating this defect, see my earlier post here <http://activemq.2283324.n4.nabble.com/5-13-1-message-blocked-td4708592.html>
I also found an unresolved defect AMQ-5260 <https://issues.apache.org/jira/browse/AMQ-5260> which has the same symptom. It looks like this issue could also be found in 5.9.x and 5.10.x. The issue is exactly as described in AMQ-5260. But we'd like to limit the code change impact within serviceRemoteConsumerAdvisory only. So below is the code change we made, Inside the addConsumerInfo call at DemandForwardingBridgeSupport.serviceRemoteConsumerAdvisory, we added a new parameter for timeout // in a cyclic network there can be multiple bridges per broker that can propagate // a network subscription so there is a need to synchronize on a shared entity synchronized (brokerService.getVmConnectorURI()) { addConsumerInfo(info*, 15000*); } And then use this timeout under protected void addSubscription(DemandSubscription sub*, int timout*) throws IOException { if (sub != null) { if (isDuplex()) { // async vm transport, need to wait for completion localBroker.request(sub.getLocalInfo()*, timout*); } else { localBroker.oneway(sub.getLocalInfo()); } } } So the difference is, when the dead lock happened, the localBroker may throw RequestTimedOutIOException if there is a dead lock. What could be the impact if addSubscription() hit timeout? why it is set to be forever wait at the first place? Thanks, -Yang -- View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-duplex-network-connector-dead-lock-5-13-1-5-11-1-tp4708953.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
