activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMQ-5467) AMQP transaction may fail to commit, or process unexpected messages, if consumer acks are not in a single unbroken sequential range
Date Mon, 01 Dec 2014 18:41:12 GMT

     [ https://issues.apache.org/jira/browse/AMQ-5467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robbie Gemmell updated AMQ-5467:
--------------------------------
    Attachment: 0001-AMQ-5467-update-AMQP-commit-processing-to-use-indivi.patch

Attaching patch to resolve issue. Adds a test that shows issue due to the client not releasing
unconsumed prefetched messages during rollback. Also fixes up some constants to improve readability
of tests using transacted sessions. 

(I have a further test elsewhere for a new client, which shows the underlying issue due to
client-side priority handling).

> 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
>
>         Attachments: 0001-AMQ-5467-update-AMQP-commit-processing-to-use-indivi.patch
>
>
> 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)

Mime
View raw message