As far as I know, the stats cover only the time since the broker was last restarted, so seeing zeros is no guarantee that there are no pending messages in the persistence store. I would use a JMX viewer such as JConsole to look at what the broker thinks is the current status of the consumer(s) on the topics in question.
Are the subscribers to your topics using durable or non-durable subscriptions? I assume durable... I don't understand the logic that led you to conclude that riderride.chat.209 is preventing log file #6 from being GC'ed. As I read your logs, what I see is that: - riderride.chat.200 prevents #2 from being GC'ed - riderride.chat.206 prevents #4 from being GC'ed - passengerride.user.1234567890 prevents #6 from being GC'ed - chat.9206705762 prevents #1 from being GC'ed - invitationStatus.1234567890 prevents #5 from being GC'ed Log #6 is blocked by passengerride.user.1234567890, and riderride.chat.209 doesn't block anything. What am I missing? Tim On May 17, 2016 7:11 AM, "Shobhana" <shobh...@quickride.in> wrote: > 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. >
