[
https://issues.apache.org/jira/browse/AMQ-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQ-3326.
-------------------------------
Resolution: Fixed
Fix Version/s: 5.6.0
Assignee: Timothy Bish
Confirmed the serialization of calls into those methods is not needed when the
inactivity purge is not running so a reader / writer lock is the correct choice.
> 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.4.2, 5.5.0
> Reporter: Izzy Alanis
> Assignee: Timothy Bish
> Fix For: 5.6.0
>
> Attachments: RegionBroker-542.patch, RegionBroker-trunk.patch
>
>
> 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
