[
https://issues.apache.org/jira/browse/ARTEMIS-4284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully updated ARTEMIS-4284:
--------------------------------
Description:
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 fix is to wait for the operation context complete on handling the
removeConsumer command.
was:
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.
> 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 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)
