AbstractRegion.lookup()
<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.activemq/activemq-broker/5.11.1/org/apache/activemq/broker/region/AbstractRegion.java#AbstractRegion.lookup%28org.apache.activemq.broker.ConnectionContext%2Corg.apache.activemq.command.ActiveMQDestination%2Cboolean%29>
has two copies of the following code:
455 destinationsLock.readLock().lock();
456 try {
457 dest = destinations.get(destination);
458 } finally {
459 destinationsLock.readLock().unlock();
460 }
destinations is a ConcurrentHashMap. Why are we using a single external
lock around a ConcurrentHashMap??? We've got lots of similar code
elsewhere in AbstractRegion. I suspect that the primary goal is to make
sure that addDestination() and receiveDestination() don't create or remove
the same destination twice, but there are other ways to do that (for
example, having the map be ConcurrentHashMap<ActiveMQDestination,
AtomicReference<Destination>> and putting the AtomicReference into the map
immediately and then later populating the reference once the object is
constructed).
I've submitted https://issues.apache.org/jira/browse/AMQ-6226 to capture
that proposed improvement.
BTW, although I'm sure that the bug Chris referenced can't hurt, it doesn't
appear to be related to the apparent root cause of your issue, so I'd
expect you'll see little or no improvement in 5.13.2. But it's definitely
worth testing to be sure.
Tim
On Mar 30, 2016 5:17 AM, "Christopher Shannon" <
christopher.l.shan...@gmail.com> wrote:
> Also, the bug fix should at least help the performance on start up but may
> not help with the producer timing out problem. The main issue is that the
> message has to be dispatched to all subscriptions before the ACK can be
> sent back to the producer, so if you have a lot of subscriptions (such as a
> wildcard subscription on a lot of topics) this could cause ACKs to be slow.
>
> On Tue, Mar 29, 2016 at 8:53 PM, Shobhana <shobh...@quickride.in> wrote:
>
> > Thank you Christopher for your suggestion. I'll check this with 5.13.2
> >
> >
> >
> > --
> > View this message in context:
> >
> http://activemq.2283324.n4.nabble.com/ActiveMQ-with-KahaDB-as-persistent-store-becomes-very-slow-almost-unresponsive-after-creating-large-s-tp4709985p4710043.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> >
>
