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?):

1. why is the test in channel.py:102 like so:
if callback and not isinstance(callback, types.FunctionType) and \
not isinstance(callback, types.MethodType):
raise TypeError("callback should be None, a function or method.")

i.e. why isn't is just a callable() test e.g.
if callback and not callable(callback):
raise TypeError("callback should be callable.")

(is this a python-3 compatibility thing?)


2. documentation for callback functions is mostly non-existent, and when it
exists is sometimes wrong e.g. on http://pika.github.com/channel.html :

(i) channel.basic_get:
"callback method signature should have 3 parameters:
The method frame, header frame and the body"
In fact the callback gets 4 parameters:
channel, method (Basic.GetOk), properties (Basic.Properties), body

(ii) channel.add_on_close_callback:
"The callback function should receive a frame parameter."
In fact the callback gets 2 parameters: error_code, error_message


3. why does basic_ack cause this warning?
CallbackManager.add: Duplicate callback found for "0:Connection.CloseOk"
i.e. why does it appear to add a(nother) connection close callback?
I've grubbed through the pika source but can't see how/where it happens.


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.


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?

Alistair

Search Discussions

  • Simon MacMullen at Feb 29, 2012 at 10:28 am

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedFeb 29, '12 at 1:54a
activeFeb 29, '12 at 10:28a
posts2
users2
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2021 Grokbase