[rabbitmq-discuss] py-amqplib status messages

Fri Nov 21 16:46:53 GMT 2008

Ben Hood wrote:
> Tsuraan,
>
> On Fri, Nov 21, 2008 at 3:27 PM, tsuraan <tsuraan at gmail.com> wrote:
>   
>>> Why are you using tx in the above? It won't do any harm, but it doesn't
>>> seem to serve any purpose.
>>>       
>> It's a stripped-down version of a larger program that does use a
>> transaction in a less wasteful fashion.
>>     
>
> That still doesn't explain why you're using it though. It is for
> intents and purposes, a semantic NOOP.
>
>   
>> 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.
>>     
>
> I'm slightly confused. You're now talking about about the sending side
> but your code beforehand was an example of a consumer.
>
> As an aside, on the sending side, you could use the immediate or
> mandatory flags to get the broker to *indicate it's inability* to
> deliver a message without you having to use a transaction, but I'm not
> sure those are the semantics you want.
>
> Ben
>   
my guess...

It sounds like he just wants to know at some point whether all messages
sent were actually received.    The acknowledgements go on at the
protocol level, well and good.   It isn´t clear how the client 
application will ´know´
that the messages sent were acknowledged.

is there a configuration where ´wait´ will block until all pending 
messages are acknowledged ?

> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20081121/2bcfa094/attachment.htm 