[
https://issues.apache.org/jira/browse/ARTEMIS-3464?focusedWorklogId=649991&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-649991
]
ASF GitHub Bot logged work on ARTEMIS-3464:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 13/Sep/21 12:52
Start Date: 13/Sep/21 12:52
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_r707304086
##########
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:
It isnt safe because it fails to ensure that there are 2 scheduled,
since the incrementing and decrementing here isnt suitably coordinated with the
worker threads task preparation and decrementing after the work is done.
Increments here can cause subsequent requesters not to schedule anything, if
they arrive before the effect of those increments is removed, but after the
effect of the worker thread task prep or decrement take place. As a result,
they may not schedule when actually they needed to.
E.g: If more than 2 threads are trying to add scans and call performScanAck,
while simultaneously a prior executing scan is just about to mark it that it
already completed its work by decrementing and the other scheduled scan can
then begin being executed, a 3rd+ requester thread at that point may not
schedule anything here due to a prior 2 incrementing the count (whilst it was
already 2+ from the prior about-to-complete and scheduled tasks, making it 4+).
However the previously-executing scan may just complete (knocking 1 from the
probably-still-4+ scheduledScanCount value, thus not taking it below the point
another will yet be scheduled) and causing the other already scheduled task to
begin and read all the tasks at the time...but perhaps occurring before it
might including those of a 3rd+ new requester, and before the 1st+2nd new
requesters then eventually decrement the count as they didnt schedule anything.
Nothing prevents those requester decrements only happening after the scan list
was already read by the second executing worker task, but before the 3rd+ new
requesters adds their scans to the intermediate list, meaning they then dont
schedule an execution because the count is still 2+. If so their scans would
stay in the intermediate list and it never get executed until a later requester
comes along to add a further request after enough decrements have occurred to
make it then actually schedule something.
--
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: 649991)
Time Spent: 3h 20m (was: 3h 10m)
> 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 20m
> 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)
