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" <shobh...@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. >
