activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Posta (JIRA)" <>
Subject [jira] [Commented] (AMQ-4196) Race condition between removal of subscriptions and removal of destinations in a network of brokers
Date Tue, 04 Dec 2012 18:26:58 GMT


Christian Posta commented on AMQ-4196:

Only 1 dispatch thread for all Topics? Then what were all those leaked threads we came across
as one of the consequences of this consumer leak? We had threads for every temporary topic
and for every advisory destination.

Yes, that's correct. There is a thread for the topic, but it's used for dispatching messages
that were set aside because of producer flow control when sent with a producer window or sent
synchronous. That's the only purpose for that thread. It does not dispatch the messages in
normal cases. Even in the PFC case, it will not race because the Usage#usageMutex would allow
the messages waiting for space to fire first before any new messages are sent.

However, I agree to the extent that consumers to temporary destinations should be tied to
the life of the temporary destination (whether a network sub or real sub). In other words,
if somehow there is a consumer for a temp dest around when the temp dest is being removed,
then that consumer too should be removed. 

I think Gary's patch will enforce this at the bridge level, but further assurances should
be fine.

> Race condition between removal of subscriptions and removal of destinations in a network
of brokers
> ---------------------------------------------------------------------------------------------------
>                 Key: AMQ-4196
>                 URL:
>             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 

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:

View raw message