Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Wed, 18 May 2011 17:54:47 +0000 (UTC)
From: "Izzy Alanis (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: 
 <35050591.23011.1305741287494.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Created] (AMQ-3326) Synchronization point in RegionBroker
 adding and removing producers and consumers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Synchronization point in RegionBroker adding and removing producers and consumers
---------------------------------------------------------------------------------

                 Key: AMQ-3326
                 URL: https://issues.apache.org/jira/browse/AMQ-3326
             Project: ActiveMQ
          Issue Type: Improvement
          Components: Broker
    Affects Versions: 5.5.0, 5.4.2
            Reporter: Izzy Alanis


Synchronization blocks were added to the RegionBroker as a result of AMQ-2821 (automatic removal of inactive destinations). I believe the author was trying to prevent adding and removing producers while the inactive destination removal process was running.

This is a major performance bottle neck in use case scenarios where many clients are subscribing and unsubscribing simultaneously -- specifically, in order to retrieve one and only one message from a queue using the STOMP protocol (without holding onto a prefetch message) you must subscribe, retrieve a message and then unsubscribe from the destination. This activity causes lots of adding and removing of producers and consumers.

I'm still not entirely convinced that the destination removal process needs to be protected in that manner, but the attached patch uses a ReentrantReadWriteLock to continue to protect the destination removal process, while still allowing clients to add and remove producers and consumers concurrently when the destination process is not running.

This patch also relates to AMQ-3070 (where the user was complaining about this same synchronization block).

I'm attaching patches both for the trunk and for 5.4.2 (which is what I'm still using).

There are other synchronization blocks further down in the code (inside AbstractRegion and Queue implementations), but in my particular use case, the 2-3x performance enhancement I get of this patch alone are enough to satisfy my immediate concerns.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira