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

[Alexis Richardson]

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