Thanks for your reply. > On 27 Sep 2016, at 14:59, Tim Bain <tb...@alumni.duke.edu> wrote: > > Do the stats you see in JConsole line up with KahaDBJournalReader (what's > that?), or with the web console? And do you see an open XA transaction in > JConsole, like Steve did?
No traces of XA transactions. > I'd guess that the negative values indicate that whatever code you > hacked'n'slashed has a bug, either in the code you started with or in the > code you changed/added. But that's pure guesswork. Highly possible. The java isn't strong in this one… > The interesting part of your email (for me) is the sentence "the only thing > that seems correct is the amount of messages in > ActiveMQ.DLQ.Queue.queue1.test," > which implies that you know you have messages in the DLQ and aren't doing > anything about it. By any chance, are one or more of those messages > exactly as old as your oldest data file? If you purge that queue (and all > other DLQs), do your data files disappear? Yes. The DLQs haven't been reciving a lot of love since this is a staging environment. I thought I tested to purge the DLQs, but apperantly not. Did it now and all the log files disappeard and freed a lot of disk. Maybe I didn't wait until the gc before checking the disk usage last time. This might be a dumb question, but it feels like the messages in DLQ took a lot more storage then "regular" messages. Is this since they are spread over many log files? Is it possible to "defrag" the log files without purging the queues? > enableAckCompaction only compacts acks, not unconsumed messages. It will > eliminate any data file being kept solely for acks, but by definition > that's not your first data file (that one must have an unconsumed message) > and if you have unconsumed messages in later files it won't compact them > either. It might be a problem if your goal is to have fewer journal files, > but you're OK with still having some, but if you want to get rid of all the > old ones, you need to make sure you're not holding old unconsumed messages. Ok! My goal is to not fill disk. So it seems like handling the DLQ is a better way to do it. -- jocar
