[rabbitmq-discuss] Missing Cancel-OK frame

[Martijn Otto]

Ah, I had totally missed that part of the specification. The problem is
indeed solved by waiting for the Cancel-OK frame to arrive before
continuing. Thanks for pointing that out to me.

I am puzzled, however, why the flow-ok method is not a synchronous
method. All of the other '-ok' methods are marked as synchronous.

I don't really get that concept. An OK frame should only be sent as a
result of receiving a frame (in this case the 'flow' frame). If that
other frame is synchronous, the server would have nothing else to send
(because nothing else should have been received before sending the
response). I don't see what is gained by making this method asynchronous
and I don't understand how it would work.

Sorry if I'm asking stupid questions here.

On Mon, 2014-04-28 at 14:37 +0100, Matthias Radestock wrote:
> On 28/04/14 14:26, Martijn Otto wrote:
> > I am working on an AMQP library for RabbitMQ and either I am missing
> > something totally fundamental, or RabbitMQ is failing in its duty to
> > send me a Cancel-OK frame to confirm consuming has stopped.
> 
> You are pipelining synchronous commands. The AMQP spec does not
permit 
> that, so the behaviour is undefined. See the pseudo code in section 
> 2.2.2 of https://www.rabbitmq.com/resources/specs/amqp0-9-1.pdf.
> 
> Matthias.