Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Message-ID: <1964893057.1220885755648.JavaMail.jira@brutus>
Date: Mon, 8 Sep 2008 07:55:55 -0700 (PDT)
From: "Gary Tully (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Updated: (AMQ-1347) Producer advisory topic is not always
 deleted with the related destination
In-Reply-To: <4016026.1185527508888.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/activemq/browse/AMQ-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Tully updated AMQ-1347:
----------------------------

    Fix Version/s: 5.3.0
                       (was: 5.2.0)

> Producer advisory topic is not always deleted with the related destination
> --------------------------------------------------------------------------
>
>                 Key: AMQ-1347
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1347
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 4.1.1, 5.2.0
>         Environment: Sun Ultrasparc under Solaris 10, Oracle JDBC, no journal. activemq svn 4.1 branch or trunk
>            Reporter: Manuel Teira
>             Fix For: 5.3.0
>
>
> When a destination is deleted, the AdvisoryBroker tries to delete the producer and consumer related advisories, in AdvisoryBroker.removeDestination and AdvisoryBroker.removeDestinationInfo. But consider the following scenario:
> HostA holds a consumer on q0.
> HostB wants to send a message and get a reply from HostA. So, it creates a producer on q0, and a temporary Queue tq on the same session. Then, sends a request message to q0 with the jmsReplyTo pointing to tq.
> HostA gets the message, and creates a producer on the temporary queue. This fires the AdvisoryBroker producer advisory topic creation for the temporary queue. 
> HostA sends a new message on the temporary queue producer, and *closes it*.
> HostB gets the message, closes the session (what automatically closes the temporary queue consumer and the q0 producer) and *removes the temporary queue*.  When HostB removes the temporary queue, the AdvisoryBroker tries to delete the related consumer and advisory topics related with the temporary queue.
> Two things can happen:
> # If HostA removeProducer command reaches the Broker before HostB removeDestination for the temporary queue, everything works fine.
> # If HostB removeDestination command reaches the broker before HostB removeProducer, the producer advisory topic for the temporary queue is deleted and then autocreated again at the AbstractRegion domain, because removeProducer fires a producer advisory message. This time, the producer advisory topic is never released, causing leakage and grief.
> As a "temporary" solution, I've disabled producer advisories for temporary queues, and things seems to work, as I don't need those advisories, using something like this in AdvisoryBroker:
> {code:title=AdvisoryBroker.java}
>   public void addProducer(ConnectionContext context, ProducerInfo info) throws Exception {
>         next.addProducer(context, info);
>         // Don't advise advisory topics.        
>         if( info.getDestination()!=null && !AdvisorySupport.isAdvisoryTopic(info.getDestination()) 
>                 && !info.getDestination().isTemporary()) { 
>             ActiveMQTopic topic = AdvisorySupport.getProducerAdvisoryTopic(info.getDestination());
>             fireAdvisory(context, topic, info);
>             producers.put(info.getProducerId(), info);
>         }
>     }
> {code}
> and the same thing for removeProducer.
> I think the problem not only applies to the temporary queues, but with their usage pattern, this bug is really problematic. 
> Consider this as a dirty hack. I expect a better and brilliant solution to be released by the activemq brains. ;-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.