[
https://issues.apache.org/jira/browse/ARTEMIS-3464?focusedWorklogId=649959&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649959
]
ASF GitHub Bot logged work on ARTEMIS-3464:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 13/Sep/21 11:59
Start Date: 13/Sep/21 11:59
Worklog Time Spent: 10m
Work Description: gemmellr commented on a change in pull request #3737:
URL: https://github.com/apache/activemq-artemis/pull/3737#discussion_r707239677
##########
File path:
artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/cursor/impl/PageSubscriptionImpl.java
##########
@@ -153,7 +157,7 @@ public void performScanAck() {
// we should only have a max of 2 scheduled tasks
// one that's might still be currently running, and another one lined up
// no need for more than that
- if (scheduledScanCount.incrementAndGet() < 2) {
+ if (scheduledScanCount.incrementAndGet() <= 2) {
Review comment:
This was obviously quite broken before the change, but even afterwards
it still seems brittle and could leave scans hanging around to get executed
until another request comes along (assuming it does).
Its still racey because the count is only decremented by the worker thread
after the the scans are actually performed, but it prepares the list of scans
to operate on at the start before doing any, whilst these
increment-then-decrement adjustments by the performScanAck requester threads
can overlap with the whole process. This could mean that the tasks to operate
on by the last executing task have already been prepared, but no task might get
scheduled here by a new requester when it should have, as the number of
requesters incrementing the value means that it seems there is a scheduled job
that will handle it when there isnt (and they then subsequently decrement the
value accordingly).
I think the worker needs to update the value before it prepares its local
scan list to operate on, so this counter speaks only to future scheduled scan
work (it could probably be a boolean at that point) or the 'add + perform'
steps collapsed into one that isnt susceptible to this issue.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 649959)
Time Spent: 3h (was: 2h 50m)
> Mirror could Miss Acks with Paging
> ----------------------------------
>
> Key: ARTEMIS-3464
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3464
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
> Affects Versions: 2.18.0
> Reporter: Clebert Suconic
> Assignee: Clebert Suconic
> Priority: Major
> Fix For: 2.19.0
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> The Mirror target could miss acks in some cases with Paging.
> We should add a scan for when the message couldn't be reached within depaged
> messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
