We use AMQ to exchange MQTT messages. I observed that the log files in Kaha DB don't get deleted even after many days.
I used the steps mentioned in http://activemq.apache.org/why-do-kahadb-log-files-remain-after-cleanup.html <http://activemq.apache.org/why-do-kahadb-log-files-remain-after-cleanup.html> to locate which destination is containing unacked messages or slow consumer. Following is the trace log output : 2016-05-17 18:05:32,077 | TRACE | Last update: 7:1109948, full gc candidates set: [1, 2, 3, 4, 5, 6, 7] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,078 | TRACE | gc candidates after producerSequenceIdTrackerLocation:7, [1, 2, 3, 4, 5, 6] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,078 | TRACE | gc candidates after ackMessageFileMapLocation:7, [1, 2, 3, 4, 5, 6] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,079 | TRACE | gc candidates after tx range:[null, null], [1, 2, 3, 4, 5, 6] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,079 | TRACE | gc candidates after dest:1:riderride.chat.200, [1, 3, 4, 5, 6] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,081 | TRACE | gc candidates after dest:1:riderride.chat.203, [1, 3, 4, 5, 6] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,081 | TRACE | gc candidates after dest:1:riderride.chat.206, [1, 3, 5, 6] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,083 | TRACE | gc candidates after dest:1:riderride.chat.209, [1, 3, 5, 6] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,083 | TRACE | gc candidates after dest:1:passengerride.user.1234567890, [1, 3, 5] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,083 | TRACE | gc candidates after dest:1:passengerride.user.1234567891, [1, 3, 5] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,085 | TRACE | gc candidates after dest:1:passengerride.status.160, [1, 3, 5] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,089 | TRACE | gc candidates after dest:1:riderride.chat.218, [1, 3, 5] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,090 | TRACE | gc candidates after dest:1:invitationStatus.1234567891, [1, 3, 5] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,090 | TRACE | gc candidates after dest:1:chat.9206705762, [3, 5] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,090 | TRACE | gc candidates after dest:1:invitationStatus.1234567890, [3] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker 2016-05-17 18:05:32,091 | TRACE | gc candidates after dest:1:riderride.chat.220, [3] | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker As per description given in the link mentioned above, there must be some unacked messages or slow consumers on topic riderride.chat.209 which is preventing log file # 6 to be GCed. However, when I check in the admin console to see how many messages were exchanged on this topic, I see that the enqueued and dequeued messages are 0. So there is no chance for any unacked messages. There is 1 inactive subscriber though. Will this inactive subscriber prevent the GCing of this log file? Same issue is observed for all other log files too. Any idea what's going wrong here? -- View this message in context: http://activemq.2283324.n4.nabble.com/AMQ-5-13-2-Kaha-DB-logs-cleanup-issue-tp4712046.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
