[
https://issues.apache.org/jira/browse/AMQ-5354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-5354.
-----------------------------
Resolution: Fixed
Fix Version/s: 5.11.0
patch applied with thanks :-)
https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=commit;h=a0c42a61
> persistJMSRedelivered feature breaks the ability for KahaDB to compact its
> journal files
> ----------------------------------------------------------------------------------------
>
> Key: AMQ-5354
> URL: https://issues.apache.org/jira/browse/AMQ-5354
> Project: ActiveMQ
> Issue Type: Bug
> Components: Message Store
> Affects Versions: 5.10.0
> Reporter: Jesse Fugitt
> Assignee: Gary Tully
> Priority: Critical
> Fix For: 5.11.0
>
> Attachments: AMQ5354.patch, activemq.log
>
>
> While doing testing with persistJMSRedelivered enabled in the ActiveMQ config
> file (which is new in 5.10), it became obvious that the KahaDB transaction
> log files are never being compacted even though all messages had been
> consumed. This is very easy to reproduce using a standard config with the
> following policyEntry to enable the feature:
> <destinationPolicy>
> <policyMap>
> <policyEntries>
> <policyEntry queue=">"
> persistJMSRedelivered="true"></policyEntry>
> After waiting several minutes it was obvious the KahaDB transaction logs
> (~2500 files using 30GB of disk space) were not getting compacted and a log
> with DEBUG enabled (attached) shows that the files are getting filtered out
> as gc candidates.
> Since the updateMessage function is essentially doing a second "add message"
> operation down in KahaDB, it appears that the reference to the original
> message is not being cleaned up from the locationIndex preventing compaction
> of any message.
> I will attach a patch that fixes the issue but this appears to be a pretty
> critical issue when using the persistJMSRedelivered feature.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
