activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Bain (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMQ-5824) Improve performance of ManagedRegionBroker.removeConsumer()
Date Wed, 03 Jun 2015 13:52:38 GMT
Tim Bain created AMQ-5824:
-----------------------------

             Summary: Improve performance of ManagedRegionBroker.removeConsumer()
                 Key: AMQ-5824
                 URL: https://issues.apache.org/jira/browse/AMQ-5824
             Project: ActiveMQ
          Issue Type: Bug
          Components: Broker
    Affects Versions: 5.11.1
            Reporter: Tim Bain
            Priority: Minor


In a Users mailing list post (http://activemq.2283324.n4.nabble.com/More-ActiveMQ-hotspots-courtesy-of-continuous-profiling-td4697159.html),
Kevin Burton noticed that ManagedRegionBroker.removeConsumer() was taking 50% of his CPU cycles
because we're iterating through all subscriptions looking for ones that match a given ConsumerInfo.
His scenario's a little unique because he uses far more destinations (and far more consumers)
than most installations, but it still highlighted a potential performance improvement.

He proposed that we keep a Map<ConsumerInfo, Subscription> (does it need to be a Multimap?)
in addition to the Map<Subscription, ObjectName> so we can quickly find the Subscription
or Subscriptions for the given ConsumerInfo.

Note that even using a concurrent collection won't synchronize between the two nor synchronize
with logic that tests the existence of an element in the collection and then acts accordingly.
 subscriptionMap already has this problem, so simply using a concurrent Map/Multimap without
doing additional synchronization may not make it worse, but we really should evaluate whether
we need explicit synchronization rather than relying on the concurrent collection as the sole
means of synchronization.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message