[jira] [Created] (AMQ-5467) AMQP transaction may fail to commit, or process unexpected messages, if consumer acks are not in a single unbroken sequential range

["Robbie Gemmell (JIRA)" <ji...@apache.org>]

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)