[rabbitmq-discuss] [help] [beginner] testing with pika: some questions and complaints

Wed Feb 29 10:28:18 GMT 2012

On 29/02/12 01:54, Alistair Bayley wrote:
> I've been testing rabbitmq with pika (python) to understand how they
> interact and learn about the AMQP protocol. I've some questions and
> some complaints; no doubt much of this will be from my
> misunderstandings of the AMQP/rabbitmq specs.
>
> Pika (is this better posted to the pika mailing list?):

Maybe?

> AMQP/rabbitmq:
>
> 4.  why doesn't basic_ack do what I expect?
>      If I do a basic_get with no_ack=False, and then a basic_ack,
>      the message stays on the queue.
>      I can repeatedly fetch-and-ack it, and each time redelivered=true.

That sounds like somehow the ack is malformed somehow (wrong ack tag?) 
and instead taking the channel / connection down. Is anything showing up 
in the server logs at this point?

> 5.  if the server reaches a state where it stops accepting messages
>      (e.g. memory usage exceeds the high water mark) it does not send
>      nack or return responses to basic_publish.
>      This is both with transactions, or with channel confirm_delivery
>      enabled.
>
>
> (5) is a concern when one requires guaranteed delivery. Having the
> server swallow the message and not respond doesn't seem reliable to
> me. Is there some other method I should be using for guaranteed
> delivery?

The server is not swallowing the message without responding; it's 
stopped accepting messages altogether, and will (eventually) send 
confirms for everything it's accepted. However, in this scenario you're 
presumably hammering the server with messages, and in that case there 
can be lots of messages waiting in the OS TCP buffers - RabbitMQ hasn't 
seen them at all.

It's not clear what else RabbitMQ could do in this situation - for 
guaranteed delivery you need to treat the message as the producer's 
responsibility until you see the confirm or tx.commit-ok.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware