activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: RFE , print that LevelDB is doing a recovery...
Date Mon, 02 Feb 2015 14:00:36 GMT
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?

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

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.


On Sun, Feb 1, 2015 at 2:44 PM, artnaseef <> 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:
> Sent from the ActiveMQ - User mailing list archive at


Location: *San Francisco, CA*
… or check out my Google+ profile

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