It is possible that there is a bug in the ack compaction feature, but if so it only shows itself in some very special cases. I have tried stressing it, but to no avail. In all my tests the broker does the right thing.
There are no cron jobs deleting any files in this system. The broker thinks that the KahaDB database is structurally sound. No complaints about any missing files during startup. When we looked in the logs of our other applications we could see that the resurrected messages were processed as expected, when expected, including a transactional commit to the broker. Before the broker was taken down the queue was empty, with matching EnqueueCount and DequeueCount. The TRACE level idea is great and will probably show what is happening, but I am afraid of running out of disk space. The logs would be huge as we need to run the system for several months before the issue happens. The broker is running on a virtual machine with limited available disk. There is also the performance impact to take into consideration. We would need to do some performance measurements before trying this in production. If the performance impact is not too bad, then we could ask for a proper disk to be added to the machine and move the logging there with the TRACE enabled. My current plan is to take a copy of the kahadb directory once a week and take a look at it. I have found some utilities that shows the contents of those files. Right now the error has not yet occurred, but it has only been running for a week so far since the last restart. -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
