[rabbitmq-discuss] py-amqplib status messages
dmitriy.samovskiy at cohesiveft.com
Tue Nov 25 17:08:32 GMT 2008
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
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):
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.
More information about the rabbitmq-discuss