[rabbitmq-discuss] Handling network reliability problems on the publisher side

[Stefan Kaes]

Thx for the quick answer.

I think we'll experiment with transactions and how how that works out.

-- stefan


Am 13.12.10 16:42 schrieb "Simon MacMullen" unter <simon at rabbitmq.com>:

> On 13/12/10 15:17, Stefan Kaes wrote:
> <snip>
> 
>> It looks like no programming cleverness on our side can achieve what we
>> want: have the publisher block as soon as a message cannot be accepted
>> by the intended rabbitmq server, because, as far as we understand the
>> amqp protocol, no protocol level acknowledgements are sent which the
>> publisher could wait for (and optionally timeout), before sending the
>> next message.
>> 
>> This is all fine to achieve high throughput on the publisher side, but
>> doesn¹t quite fit our use case. For some messages, we really need to
>> make reasonably sure the message has been received by a rabbitmq server,
>> before we continue. We could then use timeouts to detect network
>> partitioning and buffer messages locally until they can be sent (only if
>> none of our three redundant servers can be reached, of course).
> 
> <snip>
> 
>>     * is the analysis correct?
> 
> Yes. Publishes are fully async in AMQP.
> 
>>     * is the JSON-RPC plugin stable enough to be used in production?
> 
> Interesting question. Our official position is that like all the plugins
> it is "unsupported". However it's pretty clear that some plugins are
> more supported than others, and JSON-RPC is pretty low down the pecking
> order.
> 
>>     * maybe there¹s a better solution available?
> 
> The next release will feature publisher acknowledgements, where Rabbit
> will stream basic.acks back at you (if you ask for that). This sounds
> like exactly what you're looking for.
> 
> In the meantime, you could get away with publishing inside a
> transaction. When you commit the transaction, and get commit-ok back,
> you know Rabbit has got the message (and persisted it if it's
> persistent). Unfortunately this imposes a cost per commit - tweak the
> number of publishes per commit to tune performance versus maximum number
> of outstanding messages.
> 
> Cheers, Simon

Dr. Stefan Kaes
Principal System Architect
 
XING AG
Gaensemarkt 43, 20354 Hamburg, Germany
Tel. +49 40 419131-801, Fax +49 40 419131-11
 
Commercial Reg. (Registergericht): Amtsgericht Hamburg, HRB 98807
Exec. Board (Vorstand): Dr. Stefan Groß-Selbeck (Vorsitzender), Ingo Chu,
Burkhard Blum, Michael Otto, Dr. Helmut Becker
Chairman of the Supervisory Board (Aufsichtsratsvorsitzender): Dr. Neil
Sunderland
 
Please join my network on XING: http://www.xing.com/go/invite/Stefan.Kaes

This email may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this email in error) please
notify the sender immediately and destroy this email. Any unauthorized
copying, disclosure or distribution of the material in this email is
strictly forbidden and may be unlawful.