[jira] [Commented] (AMQ-6288) Message ack compaction needs to acquire the checkpoint lock

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMQ-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15280094#comment-15280094 ] 

ASF subversion and git services commented on AMQ-6288:
------------------------------------------------------

Commit e53e340262d5e57a11464c323606529430e9b832 in activemq's branch refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=e53e340 ]

https://issues.apache.org/jira/browse/AMQ-6288

The ack compaction task now acquires the checkpoint lock while it runs
to prevent a checkpoint from running at the same time unintentionally.
Also, getJournalLocation is now protected by a try/catch to handle
errors.


> 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
>
> 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)