That thread dump shows you in LevelDB doing message replay, not destination GC; are you sure destination GC is to blame for this particular issue? And do you know how many messages were in LevelDB at startup? Thanks.
I’m unsure as we still have to use KahaDB for scheduled messages. So there are definitely a ton there. but it seems to be the total number of empty queues that get GCd on startup. I was keeping a consumer on some of the ephemeral queues, which prevented them from getting GCd. Then when I restarted my client, there were no longer any consumers. This causes a queue GC (not to be confused with a Java GC) where ActiveMQ spends all its time GCing queues and doesn’t perform any work for 20-30 minutes on end. My plan right now is to release consumers more aggressively which will allow ActiveMQ to amortize queue GC for the entire lifetime of the daemon. then I’m going to write my own scheduler system to avoid having to use KahaDB. There are definitely some performance issues here. I’m just not sure what they are. The queue GC performance doesn’t seem to necessarily involve ActiveMQ startup. Just restarting my daemon cause ActiveMQ to go into a massive performance dip where it has to spend 20-30 minutes GCing queues. Kevin On Sun, Feb 1, 2015 at 2:44 PM, artnaseef <a...@artnaseef.com> wrote: > Are the recovery times related to the number of messages stored in LevelDB > at > startup? I've seen KahaDB startup take a long time when there are a large > number of messages stored. > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/RFE-print-that-LevelDB-is-doing-a-recovery-tp4690762p4690791.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile <https://plus.google.com/102718274791889610666/posts> <http://spinn3r.com>
