[rabbitmq-discuss] py-amqplib status messages
bp at barryp.org
Sat Nov 22 17:14:23 GMT 2008
Wow, I see there's a whole big thread about the py-amqplib, I'll to
combine my comments into this one message...
> How does py-amqplib return results to the user? For example,
> basic_publish has a mandatory flag, which says that if the server
> cannot route a message, it gives an unroutable message back. How does
> the user of py-amqplib get this message? It seems like every method
> returns None all the time with the exception of basic_get, so how can
> I get server responses?
Frankly, py-amqplib doesn't deal with those return messages. The
difficulty lies in the asynchronous nature of basic_publish - the broker
*may* return a message or you may never hear anything about it, so you
can't really count on a response as to whether your message was
delivered or not.
It's really the same problem as implementing flow-control, being able to
handle messages you're not explicitly waiting for.
> Matthias Radestock wrote:
>> That is most likely due to the lack of proper channel/connection closure
>> in the producer code.
> Yup, putting in chan.close() and conn.close() gets all the messages
> delivered. Is there a way to ensure message delivery without using a
> transaction or closing the channel? Some sort of flush method, or
> another flag on the basic_publish method that I didn't notice? I've
> noticed the wait() methods, but I'm not really clear on what they do,
> or how to use them.
The client doesn't do any buffering of outgoing messages, and py-amqplib
does make flush() calls to the outgoing stream, so I'd think messages
should be fully transmitted by the time basic_publish returns.
wait() is generally used to wait for basic_deliver messages from the
broker, or internally for synchronous replies to certain methods like
basic_get. It's not suited for waiting for messages that may never
arrive (like basic_return) because it doesn't support any kind of timeout.
Ben Hood wrote:
> If you set the mandatory flag and the message cannot be routed, the
> server will send the client a basic.return command. I'm not sure
> whether a callback handler is exposed in the python library. Barry may
> be able to help out with this.
Ben is right about a handler not being exposed. But even if there were
a handler, something would need to wait for those messages (which may
never come) and dispatch to the handler. I think py-amqplib would have
to expand to make use of threading to handle those features.
> Also, what is the expected usage
> for basic_consume? Do you call it and channel.wait() in a loop, in
> the same way that basic_get is used?
The demo/demo_receive.py sample shows how basic_consume and wait are
used. You'd generally call basic_consume one time to tell the broker to
start sending messages. wait() processes a single message, so you'd
want to call that repeatedly in a loop.
> Does py-amqplib have the same limitation as the rabbitmq java
> consumer, where it calling methods on the channel or connection from
> the callback will cause deadlock? If so, how are messages
> acknowledged in basic_consume?
Using version 0.5 or higher of py-amqplib, you should be able to call
methods from a callback without worrying about deadlock. So you can
explicitly acknowledge messages in a callback, which is shown in
More information about the rabbitmq-discuss