activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Posta (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-4196) Race condition between removal of subscriptions and removal of destinations in a network of brokers
Date Mon, 03 Dec 2012 23:16:00 GMT

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

Christian Posta commented on AMQ-4196:
--------------------------------------

Art,

for (b), remove consumer (for a temp) and remove destination (for a temp) can only come from
one place (the connection it originated from), ie, another connection cannot remove the temp
or the consumer to the temp. When that connection makes a call to remove the consumer for
the temp, the thread that handles it for that connection handles the remove in the broker
and sends to the advisory topic as well as sends to the subscription for the advisory topic.
Topics don't have a separate "dispatch thread" like queues do, so the ordering for this case
cannot race. The same thread that handled the connection is also used in the TopicSubscription.
If there were two separate connections involved with sending the remove info and remove destination,
then there could be a race. 

The only other thread involved is the thread for the consumer's connection. When a topic sub
dispatches to the consumer's connection it will do this by default async. So it will be put
into a "worker queue" for the connection thread to finally send it over the wire. but the
messages are put there by the same thread and in order for this async dispatch. 

If i've mispoken, I'm open to corrections :)
                
> 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

Mime
View raw message