qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: What is AMQP 1-0 spec complaint Broker behaviour for deletion of queue with consumers attached?
Date Thu, 22 Mar 2018 11:55:41 GMT
On 20 March 2018 at 12:44, Gordon Sim <gsim@redhat.com> wrote:
> On 20/03/18 11:37, Rob Godfrey wrote:
>> How do we treat transactions which have transactionally enqueued a message
>> on the (now deleted) queue - do we allow them to commit successfully, or
>> do
>> we force a rollback?  Similarly when a message has been sent from the
>> queue
>> and accepted as part of a transaction?
> It seems the c++ broker allows the transaction to commit at present. I don't
> think that was a conscious choice though. I suspect the scenario wasn't
> explicitly planned for.
> I think the ideal behaviour would be for a transaction error to be signaled
> regardless of whether the client initiates a commit or rollback in both the
> publish and consume case where a queue involved has since been deleted.
> From the spec:
> "If the coordinator is unable to complete the discharge, the coordinator
> MUST convey the error to the controller as a transaction-error."
> To me if the queue is deleted, the transaction can't really be properly
> completed, therefore and error would be clearest.

I dont think an error should be signalled if the controller is trying
to roll back the transaction. The queue not being there anymore doesnt
seem to me like it really prevents discharging an attempt to
rollback/fail a related transaction. That may for example something an
application/client tries to do if some associated link(s) have just
been remotely closed.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message