[
https://issues.apache.org/jira/browse/AMQ-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon reopened AMQ-6288:
-----------------------------------------
We need to grab the readlock, not the writelock because the journal requires
the readlock to store to it. With the writelock everything grinds to a halt
when rewriting acks which we don't want.
> 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.4#6332)
