Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Tue, 4 Dec 2012 19:44:58 +0000 (UTC)
From: "Arthur Naseef (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: <378671622.60088.1354650298759.JavaMail.jiratomcat@arcas>
In-Reply-To: <1633581620.39823.1354195018817.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (AMQ-4196) Race condition between removal of
 subscriptions and removal of destinations in a network of brokers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/AMQ-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509957#comment-13509957 ] 

Arthur Naseef commented on AMQ-4196:
------------------------------------

Alright.  Just keep in mind that I'm tired of providing concrete test cases for issues that aren't getting fixed.  So, I'm going to stop doing so if they don't start yielding results.

For example, I still have (> 1 year now) issues with transacted sends failing and the clients never notice.

And then there's the partner to this issue in which a request message with JMSReplyTo = temp topic sent across a network of brokers, the producer can actually start sending messages before it's broker knows of the existence of the temporary destination.

So, when I produce a concerete test case for this, I expect immediate action.
                
> 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