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

[Alexis Richardson]

It would be nice to have a lazy ack and things like that will be in
future versions of amqp.

For now, have you looked at the TX class?

alexis


On Mon, Jan 4, 2010 at 9:26 PM, Chris Duncan <celldee at gmail.com> wrote:
> 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
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>