I downloaded the source code and tracked the code a little. I found the issue
could be here:
DemandForwardingBridgeSupport.java (line: 774)
// 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);
}
This synchronized block holds an java.net.URI object. And within the block,
it's sending a ConsumerAdvisory message, which is a blocking operation. It
will wait until the response get back until it quits the synchronized block.
However, in our test, we dropped responded message and the default
sendTimeout is 0 which is infinite. Therefore, this synchronized block will
never quit and in the meanwhile. since it holds the connector URI, it's
actually blocks all the sending message to this URI.
It seems configuring connection.sendTimeout should prevent this. But since
here we have a big block on URI level, should it have a non-0 default
sentTimeout?
--
View this message in context:
http://activemq.2283324.n4.nabble.com/5-13-1-message-blocked-tp4708592p4708819.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
