activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject Re: ActiveMQ with KahaDB as persistent store becomes very slow (almost unresponsive) after creating large no (25000+) of Topics
Date Sun, 10 Apr 2016 04:53:35 GMT
How are you able to tell that a single call to updateIndex() is taking 3.5
minutes?  It's not possible to determine that from thread dumps alone, so
what other tool are you using to prove that assertion?

A profiler such as JVisualVM would help you determine where precisely the
broker is spending its time, though of course it may not tell you exactly
why.  Stepping through the code with a debugger may help you figure out the
why if it's not obvious from the profiler output.  Luckily this is an open
source project and you can download the source to make that possible.

Tim
On Apr 8, 2016 11:58 AM, "Shobhana" <shobhana@quickride.in> wrote:

> Hi Tim,
>
> I said indexing was the point of contention after seeing that Thread
> "ActiveMQ NIO Worker 169" was still working on
> org.apache.activemq.store.kahadb.MessageDatabase.updateIndex even after >
> 3.5 minutes.
>
> These are full thread dumps. I guess the lock (read lock) is held by
> threads
> "ActiveMQ NIO Worker 169" and "ActiveMQ NIO Worker 171". Since the read
> lock
> is already held by other threads, the thread "ActiveMQ Broker[localhost]
> Scheduler" is waiting to acquire write lock. Since there is already a
> thread
> waiting to acquire write lock, other threads which are waiting to acquire
> read lock are still waiting.
>
> What could be the reason for updateIndex not completing even after 3.5
> minutes?
>
>
>
> --
> 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-tp4709985p4710533.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message