[
https://issues.apache.org/jira/browse/AMQ-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15851727#comment-15851727
]
ASF subversion and git services commented on AMQ-6288:
------------------------------------------------------
Commit 9b64e188b59a395300a2f5d6022df9dbbae2f426 in activemq's branch
refs/heads/master from [~gtully]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=9b64e18 ]
[AMQ-6432] issue was journal scan on newly created ack file. I left the
relevant braces from AMQ-6288 in place. Fix and test
> Message ack compaction needs to acquire the checkpoint lock
> -----------------------------------------------------------
>
> Key: AMQ-6288
> URL: https://issues.apache.org/jira/browse/AMQ-6288
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.13.3
> Reporter: Christopher L. Shannon
> Assignee: Christopher L. Shannon
> Fix For: 5.14.0
>
>
> The AckCompactionRunner task needs to acquire the checkpiont lock to prevent
> other threads from running a checkpoint while the task is running. Normally
> this task runs on the same executor as the checkpoint task so the ack
> compaction task wouldn't run at the same time as the checkpoint task as they
> are processed one at a time.
> However, there are two cases where this isn't always true. First, the
> checkpoint() method is public and can be called through the
> PersistenceAdapter interface by someone at the same time the ack compaction
> is running. Second, a checkpoint is called during shutdown without using the
> executor and could also run while the ack compaction is running.
> The main reason for this fix is because when doing some testing I was seeing
> an occasional error from journal.getNextLocation() in the forwardAllAcks
> method because a journal file was missing which I believe was cleaned up by
> the cleanup task. I was testing scenarios such as shutdown and also manually
> triggering the task at the same time as an ack compaction.
> Also, while we are at it, we should have a try/catch around the
> journal.getNextLocation calls to catch any IOException so we can abort
> gracefully.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
