Robbie Gemmell created AMQ-5467:
-----------------------------------
Summary: AMQP transaction may fail to commit, or process
unexpected messages, if consumer acks are not in a single unbroken sequential
range
Key: AMQ-5467
URL: https://issues.apache.org/jira/browse/AMQ-5467
Project: ActiveMQ
Issue Type: Bug
Components: AMQP
Affects Versions: 5.10.0
Reporter: Robbie Gemmell
Priority: Critical
Fix For: 5.11.0
When consuming messages in a transaction, the AMQP consumer accepts messages
and specifies the transaction they are part of. AMQPProtocolConverter keeps a
record of messages accepted in this way. When the transaction is committed,
AMQPProtocolConverter assumes that the first and last messages in this
'dispatched in Tx' list form a range, and creates a ranged 'standard ack'
MessageAck to cover the messages. The broker then checks that the acks it is
processing match messages it has previously dispatched, in
PrefetchSubscription#assertAckMatchesDispatched(MessageAck).
If the messages aren't added to the AMQP transaction in sequence, e.g. the
assumed 'last id' is actually for a message dispatched before the assumed
'first id' in the sequence, the check fails even though all the messages being
acked are in the dispatched list. There is also an implicit assumption in the
processing that the ack range is an unbroken sequence, and as a result it would
seem possible for messages to be acked that were not actually considered part
of the AMQP transaction. This non-sequential ordering can for example happen
because a client isn't releasing unconsumed prefetched messages after a
rollback of consumed messages, or alternatively is processing higher priority
messages before lower priority messages originally dispatched to it earlier.
To combat these issues, the AMQP transaction commit processing should be
updated to use 'individual acks'.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
