[rabbitmq-discuss] py-amqplib status messages

[Barry Pederson]

Wow, I see there's a whole big thread about the py-amqplib, I'll to 
combine my comments into this one message...

----------------

tsuraan wrote:
> 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.

----------------

tsuraan wrote:
 > 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.

-----------------

tsuraan wrote:

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


------------------


tsuraan wrote:

 > 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 
demo/demo_receive.py

	Barry