[jira] [Commented] (AMQ-6288) Message ack compaction needs to acquire the checkpoint lock
[ https://issues.apache.org/jira/browse/AMQ-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15854044#comment-15854044 ] ASF subversion and git services commented on AMQ-6288: -- Commit 93715d1bd605bc61149505d4df2ebc223ae371af in activemq's branch refs/heads/activemq-5.14.x from [~gtully] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=93715d1 ] [AMQ-6432] issue was journal scan on newly created ack file. I left the relevant braces from AMQ-6288 in place. Fix and test (cherry picked from commit 9b64e188b59a395300a2f5d6022df9dbbae2f426) > 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)
[jira] [Commented] (AMQ-6288) Message ack compaction needs to acquire the checkpoint lock
[ 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)
[jira] [Commented] (AMQ-6288) Message ack compaction needs to acquire the checkpoint lock
[ 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)
