Re: ActiveMQ with KahaDB as persistent store becomes very slow (almost unresponsive) after creating large no (25000+) of Topics

Sounds good. A profiler (as opposed to a sampler) should be able to tell you how many times a given method is called, so if you see that that's 1, then you'd be able to make the claim that a single call to updateIndex() is taking 3.5 minutes. But looking only at thread dumps, all you can say is

Re: ActiveMQ with KahaDB as persistent store becomes very slow (almost unresponsive) after creating large no (25000+) of Topics

I looked at only the thread dumps. I will profile with some profiler first and see where is the broker spending more time. -- View this message in context:

Re: ActiveMQ with KahaDB as persistent store becomes very slow (almost unresponsive) after creating large no (25000+) of Topics

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

Re: ActiveMQ with KahaDB as persistent store becomes very slow (almost unresponsive) after creating large no (25000+) of Topics

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

Re: ActiveMQ with KahaDB as persistent store becomes very slow (almost unresponsive) after creating large no (25000+) of Topics

Kevin Burton has already identified that GCing destinations is horribly inefficient when the number of destinations is large; search the archives for posts from him for more details. He has proposed some fixes (in Git, but against an earlier version), but so far as I know no one from the

Re: ActiveMQ with KahaDB as persistent store becomes very slow (almost unresponsive) after creating large no (25000+) of Topics

The CountStatisticImpl class is basically just a wrapper for an atomic long. It's used all over the place (destinations, subscriptions, inside kahadb, etc) to keep track of various metrics in a non-blocking way. There's a DestinationStatistics object for each destination and that has several of

Re: ActiveMQ with KahaDB as persistent store becomes very slow (almost unresponsive) after creating large no (25000+) of Topics

Hi Tim & Christopher, I tried with 5.13.2 version but as you suspected, it did not solve my problem. We don't have any wildcard subscriptions. Most of the Topics have a maximum of 8 subscriptions (Ranges between 2 and 8) and a few topics (~25-30 so far) have more than 8 (this is not fixed, it

Re: ActiveMQ with KahaDB as persistent store becomes very slow (almost unresponsive) after creating large no (25000+) of Topics

AbstractRegion.lookup()

Re: ActiveMQ with KahaDB as persistent store becomes very slow (almost unresponsive) after creating large no (25000+) of Topics

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

Re: ActiveMQ with KahaDB as persistent store becomes very slow (almost unresponsive) after creating large no (25000+) of Topics

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 -

Re: ActiveMQ with KahaDB as persistent store becomes very slow (almost unresponsive) after creating large no (25000+) of Topics

Can you try version 5.13.2 and see if that helps? There was a performance bug related to durables (AMQ-6158) in KahaDB that was fixed which might help here. On Tue, Mar 29, 2016 at 12:17 AM, Shobhana wrote: > I enabled debug logs to see what was happening when AMQ could

Re: ActiveMQ with KahaDB as persistent store becomes very slow (almost unresponsive) after creating large no (25000+) of Topics

I enabled debug logs to see what was happening when AMQ could not send ACK within 30 secs. I started the AMQ broker on 28-Mar around 17:40 and to my surprise, I find that the server startup is still going on even now at 29-Mar 09:30 (~16 hours!!). I see a lot of following messages in the logs :

ActiveMQ with KahaDB as persistent store becomes very slow (almost unresponsive) after creating large no (25000+) of Topics

Hi, Is there any limit to the number of Topics that can be created on a single broker? As per my understanding, there is no such limit and it depends on the system in which the broker is running. Problem observed which raised the above question : I tried to simulate an issue which occurs in our