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

[Chris Duncan]

OK. I'll keep playing. Thanks for your input.

Regards,

Chris

On 4 Jan 2010, at 23:03, Alexis Richardson wrote:

> Roughly.
>
> Using TX allows you to get a synchronous ack.  But it's comparitively
> slow obviously.  You can do acks asyncly but that has a weaker SLA of
> course.
>
> I am being vague in the hope that a better-informed person will make a
> more precise and possibly helpful statement about how to make the most
> of this ;-)
>
> Meanwhile I suggest you experiment based on what you glean from the
> spec and searching the rabbitmq.com site...
>
> alexis
>
>
>
>
> On Mon, Jan 4, 2010 at 10:57 PM, Chris Duncan <celldee at gmail.com>  
> wrote:
>> 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
>>>>
>>
>>