Return-Path: Delivered-To: apmail-activemq-dev-archive@www.apache.org Received: (qmail 93084 invoked from network); 11 Sep 2009 19:41:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 Sep 2009 19:41:37 -0000 Received: (qmail 74066 invoked by uid 500); 11 Sep 2009 19:41:37 -0000 Delivered-To: apmail-activemq-dev-archive@activemq.apache.org Received: (qmail 74020 invoked by uid 500); 11 Sep 2009 19:41:37 -0000 Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list dev@activemq.apache.org Received: (qmail 74010 invoked by uid 99); 11 Sep 2009 19:41:37 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Sep 2009 19:41:37 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Sep 2009 19:41:33 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 44B91234C4AC for ; Fri, 11 Sep 2009 12:41:12 -0700 (PDT) Message-ID: <1787507864.1252698072280.JavaMail.jira@brutus> Date: Fri, 11 Sep 2009 12:41:12 -0700 (PDT) From: "Rob Davies (JIRA)" To: dev@activemq.apache.org Subject: [jira] Assigned: (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 X-JIRA-FingerPrint: ae95407df07c98740808b2ef9da0087c X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/activemq/browse/AMQ-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Davies reassigned AMQ-1347: ------------------------------- Assignee: Rob Davies > 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 > Assignee: Rob Davies > 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.