activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Burton <>
Subject Re: A proposal to rewrite purgeInactiveDestinations locking to prevent queue GC lockups.
Date Mon, 23 Feb 2015 00:10:16 GMT
On Sun, Feb 22, 2015 at 3:30 PM, Tim Bain <> wrote:

> So if LevelDB cleanup during removeDestination() is the presumed culprit,
> can we spin off the LevelDB cleanup work into a separate thread (better: a
> task object to be serviced by a ThreadPool so you can avoid a fork bomb if
> we remove many destinations at once) so the call to removeDestination() can
> return quickly and LevelDB can do its record-keeping in the background
> without blocking message-processing?

Would that be possible?  If the delete is pending on ActiveMQ there is a
race where a producer could re-create it unless the lock is held.

Though I guess if you dispatched to the GC thread WITH the lock still held
you would be ok but I think if we use the existing purge thread then we’re

OK. I think I’m wrong about LevelDB being the issue.  To be fair I wasn’t
100% certain before but I should have specified.

Our current production broker is running with persistent=false.. .and I
just re-ran the tests without disk persistence and it has the same problem.

So the main issue how is why the heck is ActiveMQ taking SO LONG to GC a
queue.  It’s taking about 100ms which is an insane amount of time
considering this is done all in memory.



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

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