[
https://issues.apache.org/jira/browse/AMQ-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333652#comment-14333652
]
Kevin Burton commented on AMQ-5609:
-----------------------------------
My changes are here:
https://github.com/spinn3r/activemq
the branch is burton-concurrent-destination-gc
... it's testing now but I'll post the results here when the tests pass.
> ActiveMQ locks out new consumers/producers during queue GC
> ----------------------------------------------------------
>
> Key: AMQ-5609
> URL: https://issues.apache.org/jira/browse/AMQ-5609
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.10.1, 5.11.0
> Reporter: Kevin Burton
>
> ActiveMQ supports a feature where it can GC a queue that is inactive. IE now
> messages and no consumers.
> However, there’s a bug where
> purgeInactiveDestinations
> in
> org.apache.activemq.broker.region.RegionBroker
> creates a read/write lock (inactiveDestinationsPurgeLock) which is held
> during the entire queue GC.
> each individual queue GC takes about 100ms with a disk backed queue and 10ms
> with a memory backed (non-persistent) queue. If you have thousands of them to
> GC at once the inactiveDestinationsPurgeLock lock is held the entire time
> which can last from 60 seconds to 5 minutes (and essentially unbounded).
> A read lock is also held for this in addConsumer addProducer so that when a
> new consumer or produce tries to connect, they’re blocked until queue GC
> completes.
> Existing producers/consumers work JUST fine.
> The lock MUST be held on each queue because if it isn’t there’s a race where
> a queue is flagged to be GCd , then a producer comes in and writes a new
> message, then the background thread deletes the queue which it marked as
> GCable but it had the newly produced message. This would result in data loss.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
