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

[Chris Duncan]

Hi Alexis,

I have looked at it, but I obviously didn't understood it correctly.  
So, let's see if I grok this. Suppose I send a tx.select, send my  
basic.publish and then send a tx.commit. If I receive a tx.commit-ok  
all is well, otherwise I'll receive a channel exception from the server.

Not as straightforward as a publish-ok, but hey, if it works ... :)

Thanks,

Chris

On 4 Jan 2010, at 22:11, Alexis Richardson wrote:

> 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
>>