[rabbitmq-discuss] AMQP message publishing - I wish it was synchronous

[Chris Duncan]

Before I begin let me state for the record that I have read the 0-8  
and 0-9 AMQP specs and realise that they will not change just because  
I believe that it might be a good idea. Neither do I advocate  
deviation from the specs for the sake of expedience.

OK, I've been looking at including Channel.Flow method processing in  
the Bunny client (again) and have come to the conclusion that  
publishing should be synchronous in AMQP terms. My reasoning is as  
follows -

The AMQP Channel.Flow method is a device to try to prevent servers  
getting swamped by message producing clients. The server sends a  
Channel.Flow method with :active argument set to false to a producer  
in order to get the producer to stop sending messages when server  
memory is getting critically low.

When a client application publishes a message it passes that message  
into the care of the server. If something goes wrong the client  
application needs to be notified, but it is equally important for the  
client to know that the server has the message and will do its level  
best to deliver it to an appropriate destination queue. It seems to  
me that the second piece of information, namely a "yes I have your  
message", is missing. This absence of information means that the  
client has to make a judgement on the success of the publish  
operation based on what it does not receive, rather than what is does  
receive.

If, after issuing a Basic.Publish method, a client does not receive  
an error indication or Channel.Flow method, it has to assume that a  
publish has succeeded. For a simple single-threaded synchronous  
client like Bunny, the lack of a publish-ok method means that it has  
to wait to see whether a message arrives that indicates a problem. So  
in the case of Basic.Publish, the client could do a blocking read  
that times out if no message is received. However, even if I could  
rely on the timeout to work without fail (which my current testing is  
suggesting may not be the case), I don't like that solution at all.

With a publish-ok method things become much more straightforward. If  
the client receives a publish-ok then everything is rosy in the  
garden. If not, the client handles the issue. There could be  
a :nowait flag as there are for other methods for asynchronous  
processing.

If anyone has any ideas as to how I can get around this issue using  
Ruby without additional threads, fibers, eventmachine etc. I would be  
very pleased to hear from them.

Regards,

Chris