[rabbitmq-discuss] py-amqplib status messages

[Dmitriy Samovskiy]

Matthias Radestock wrote:
> 
> So unless the sender has received some application level ack - such as a 
> channel/connection.close-ok, or a tx.commit-ok - there is no way for it 
> to be sure that the messages it has sent have been
> processed.
> 
Understood. So if I don't receive an application level ack, I can't know how many messages 
  that I already sent, have been received by broker. Consider:

for i in range(1000): ch.basic_publish(Message(str(i)), 'amq.fanout')
and I get socket.error exception when i==500.

This means that I either have to do buffering inside producer in order to be able to 
resend them all, or I have to wrap each basic.publish in tx.

In latter case, it's a total of 5 methods (tx.select, tx.select-ok, basic.publish, 
tx.commit, tx.commit-ok). *If* AMQP spec offered a synchronous publish, it would be only 2 
methods (basic.publish-with-confirmation, basic.publish-ok).

I take it there must be a reason why only async version of publish method is provided in 
AMQP spec? Is anyone familiar with reasoning behind this decision?


On a side note, I found that if I sleep after each send in the above loop, I get 
consistently higher success rates of received vs not received messages with py-amqplib on 
Linux (essentially no message loss due to being in flight).

for i in range(1000):
   ch.basic_publish(Message(str(i)), 'amq.fanout')
   time.sleep(0.0001)

Without sleeps, tcpdump shows multiple basic.publish methods packed in a single TCP 
packet. With sleeps, there are more TCP packets that carry the same number of 
basic.publish methods. Note that this may not be the case for other client implementations 
and could be OS dependent as well (not tested).

This may not be a good pattern to rely on, but in limited testing it worked for me.


- Dmitriy