[ https://issues.apache.org/jira/browse/AMQ-6644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully resolved AMQ-6644. ----------------------------- Resolution: Fixed > Incorrect logging from KahaDB cleanup task when enableAckCompaction=true > ------------------------------------------------------------------------ > > Key: AMQ-6644 > URL: https://issues.apache.org/jira/browse/AMQ-6644 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB > Affects Versions: 5.14.0 > Reporter: Gary Tully > Assignee: Gary Tully > Priority: Minor > Fix For: 5.15.0 > > > When KahaDB is configured for enableAckCompaction=true, it moves acks into a > new journal file. Such journal file will only contains the compacted acks, it > won't be used to hold messages. > If the actual journal (to which new messages are written to) has a lower > number than the journal files that were created during ack compaction, the > periodic cleanup task will not delete any journals that are higher than the > actual journal file. So multiple journal files may remain active on disk > although there is no single unconsumed message on the broker. > This in itself is okay, however when trace logging for the cleanup task is > enabled, it reports differently, namely that it is going to delete these > journals, where in fact it is not deleting them. > E.g. lets take the following example. > The KahaDB folder on disk consists of > {code} > [kahadb]$ ls -alh > total 54M > drwxr-xr-x. 2 fuse fuse 128K Feb 1 15:50 . > drwxr-xr-x. 13 fuse fuse 4.0K Nov 4 13:14 .. > -rw-r--r--. 1 fuse fuse 32M Feb 1 16:26 db-65.log > -rw-r--r--. 1 fuse fuse 4.6M Feb 1 15:24 db-66.log > -rw-r--r--. 1 fuse fuse 4.5M Feb 1 15:29 db-67.log > -rw-r--r--. 1 fuse fuse 4.6M Feb 1 15:34 db-68.log > -rw-r--r--. 1 fuse fuse 4.5M Feb 1 15:39 db-69.log > -rw-r--r--. 1 fuse fuse 2.5M Feb 1 16:26 db.data > -rw-r--r--. 1 fuse fuse 32M Feb 1 14:51 db-log.template > -rw-r--r--. 1 fuse fuse 1002K Feb 1 16:26 db.redo > -rw-r--r--. 1 fuse fuse 8 Feb 1 14:51 lock > {code} > and the logging says: > {code} > Last update: 65:26636520, full gc candidates set: [65, 66, 67, 68, 69] > gc candidates after producerSequenceIdTrackerLocation:65, [66, 67, 68, 69] > gc candidates after ackMessageFileMapLocation:65, [66, 67, 68, 69] > ... > gc candidates: [66, 67, 68, 69] > ackMessageFileMap: {65=[65]} > Cleanup removing the data files: [66, 67, 68, 69] > {code} > In this example the actual journal file to which msgs are written is 65. The > journal files 66-69 were created during ack compaction and have a higher > number than 65. > So KahaDB won't delete the journals 66-69 until the actual journal file is > moved to journal 70, despite that there are no unconsumed messages on the > broker. > However the last log line suggests that it will remove the journals 66-69, > but they will not get removed due to rule above. > We should align the logging output with the logic used to determine which > journals to delete. -- This message was sent by Atlassian JIRA (v6.3.15#6346)