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?

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

(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
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

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 2 | next ›
Discussion Overview
grouprabbitmq-discuss @
postedFeb 29, '12 at 1:54a
activeFeb 29, '12 at 10:28a



site design / logo © 2022 Grokbase