[
https://issues.apache.org/jira/browse/AMQ-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509145#comment-13509145
]
Gary Tully commented on AMQ-4196:
---------------------------------
@Arthur - any outstanding consumers will be network bridge local forwarding
consumers that will be removed when the remote destination is removed.
Following the normal, respond to advisories approach.
On the threading - dispatch occurs in the sending thread and so long as only
one network bridge is dealing with temp destinations, a single consumer will be
dealing with all advisories in the order in which they are produced.
Feel free to provide more test cases that can demonstrate that there still is a
problem.
> Race condition between removal of subscriptions and removal of destinations
> in a network of brokers
> ---------------------------------------------------------------------------------------------------
>
> Key: AMQ-4196
> URL: https://issues.apache.org/jira/browse/AMQ-4196
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Connector
> Affects Versions: 5.6.0, 5.7.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Labels: Temp, networkBridge
> Fix For: 5.8.0
>
>
> n a broker network like this: A <--> B <---> C
> Scenario:
> A producer to BrokerA creates a message, sets its replyTo header to a temp
> destination that it creates and listens on, then sends the message off to
> broker A. The message is demand forwarded to BrokerC because there is a
> consumer there that consumes the message and replies to the temp dest in the
> replyTo header.
> As the number of concurrent producers on BrokerA sending these messages
> increases, the subscription to the temp destination that was demand forwarded
> will not be cleaned up properly on BrokerC. The reason for this is the
> DemandForwardingBridge runs the remove consumer code in a separate thread.
> But if a "remove destination" advisory messages comes in, it will remove the
> destination from the AdvisoryBroker's destination map. So if this happens
> before the code for removeConsumer runs (in AdvisoryBroker), then the
> destination will not be in the destination map and the advisory for
> removeConsumer will not fire.
> The net result is a subscription leak in the network bridge on B & C
> The junit test shows two issues:
> 1) the subscriptions leaked when concurrent producers using request/reply and
> correctly closing the consumer and connection
> 2) all subscriptions leaked when using a single producer with request/reply
> and closing only the connection, and not the consumer explicitly
> Issue 2 is related to temp destinations only and is compounded by
> https://issues.apache.org/jira/browse/AMQ-3879
--
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
