gemmellr commented on a change in pull request #3728:
URL: https://github.com/apache/activemq-artemis/pull/3728#discussion_r705570521
##########
File path:
artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/connect/mirror/AMQPMirrorControllerTarget.java
##########
@@ -380,10 +394,7 @@ private void performAck(String nodeID, long messageID,
Queue targetQueue, ACKMes
logger.warn(e.getMessage(), e);
}
} else {
- if (logger.isDebugEnabled()) {
- logger.debug("Post ack Server " + server + " could not find
messageID = " + messageID +
- " representing nodeID=" + nodeID);
- }
+ performAckOnPage(nodeID, messageID, targetQueue, ackMessageOperation);
Review comment:
The scan is done on the same thread that reads the pages, yes...but I
dont see where there is any guarantee or coordination that the message hasnt
already depaged by that thread before we eventually get round to asking it to
do the scan for us, after trying and failing to ack the message on the queue
itself from the other IO thread?
To me it seems like the connection thread can try to ack on the queue, fail
to do so as it isnt there yet...decide to pop a scan onto the paging thread,
only for that thread to successfully depage the message while we are preparing
the request, and then be asked to remove it from the paging store and fail at
that because its no longer there anymore by the time it runs, but is now on the
queue we wont check again.
--
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]
