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

[Alistair Bayley]

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