[
https://issues.apache.org/jira/browse/ARTEMIS-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723916#comment-17723916
]
ASF subversion and git services commented on ARTEMIS-4284:
----------------------------------------------------------
Commit b664022a1ed772e74b518dd5d12f44ca53fb2f16 in activemq-artemis's branch
refs/heads/main from Gary Tully
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=b664022a1e ]
ARTEMIS-4284 - sync operwire remove consumer with the operation context to
ensure prefetched messages are available to the next consumer in order
This closes #4483
> Openwire prefetched messages can be out of order for a single consumer
> ----------------------------------------------------------------------
>
> Key: ARTEMIS-4284
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4284
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: OpenWire
> Affects Versions: 2.28.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Priority: Major
> Fix For: 2.29.0
>
>
> It is an anti pattern, but a new consumer per message loop can fail with
> openwire. the remove is non blocking, so a new consumer can co exist with the
> async cancel/add sorted of the previpous consumer. This breaks ordering that
> is required for the delivery count logic around unconsumed prefetched
> messages.
> the workaround is to use prefetch=1 but the underlying problem is real, in
> 5.x the cancel/add_sorted is done in the same thread as remove. In artemis,
> the storage manager handles this async.
> A potential fix is to wait for the operation context complete on handling the
> removeConsumer command.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
