activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: mKahaDB - no clean-up because of ACKs
Date Sat, 10 Mar 2018 04:26:32 GMT

There must have been at least one file that was kept not because of acks in
an earlier file. Presumably this would be the one with the lowest number.
Can you provide the log output for that file?

The standard guess when people say that their KahaDB files are being kept
even though there are no messages is to ask, "Did you check the DLQ?" So,
did you check the DLQ?

Alternatively, you could use a debugger to step through the code in, so you can see from the
debugger why that first file is being kept alive.

Another option, if you still can't figure out which message is keeping the
journal files alive, might be to start up a 5.14.0 broker, which had the
ack-compaction logic present, and let it squish the log files down to just
a few files, then shut down the broker and take the now-much-smaller files
back to your 5.10 broker and pick up from there.


On Fri, Mar 9, 2018 at 2:51 AM, alprausch77 <>

> Hello.
> Recently we had a problem on a ActiveMQ 5.10 version (with manually applied
> patch for AMQ-5542).
> The mKahaDB data store increased to ~30 GB and couldn´t clean up the data
> files anymore.
> The log showed always something like this:
> /not removing data file: 317633 as contained ack(s) refer to referenced
> file: [317632, 317633]/
> I´m aware that the data files can´t be cleaned up if there is a not
> consumed
> message in a queue. But that´s not the case here.
> I have started a ActiveMQ with the copied storage on my local machine and
> checked every queue and topic via JConsole if there is any message in it -
> but every queue/topic shows a size of 0.
> So it seems to me that the messages are processed but just the ACK is
> somewhat stuck in the store.
> Is there a way to (manually) get rid of the ACKs?
> Or is there a way to have a deeper analysis of the kahaDB storage files to
> find the reason for the stucked ACKs?
> I can provide the whole log with the KahaDB recovering if this is of any
> help.
> Thanks.
> Joachim
> --
> Sent from:
> f2341805.html

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