activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher L. Shannon (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (AMQ-6288) Message ack compaction needs to acquire the checkpoint lock
Date Wed, 11 May 2016 13:20:12 GMT

     [ https://issues.apache.org/jira/browse/AMQ-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Christopher L. Shannon resolved AMQ-6288.
-----------------------------------------
       Resolution: Fixed
    Fix Version/s: 5.14.0

This has been resolved.  In the future it may make sense to get rid of the checkpoint lock
entirely and only run the tasks on the executor.  The existing points in the code that run
the checkpoint as sync could just use a future and wait for it to finish, etc.  I think this
would work ok without the lock but would still need to look closer at it and make sure no
issues would pop up.

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

Mime
View raw message