[rabbitmq-discuss] Question/clarification wrt durable messages

[Brian Parkinson]

Hi Emile:

Ran the tests under a transaction, and the messages certainly survive a server (node) crash.

The throughput I'm getting is approximately 10 messages per second - does this gibe with what you would expect for throughput? I ask, as it seems slow compared to non-tx, even taking into account the time for persistence. I'm wrapping the call to basicPublish with txSelect and txCommit.

Thanks.

b...



On Dec 17, 2010, at 8:43 AM, Emile Joubert wrote:

> Hi Brian,
> 
> On 16/12/10 20:03, Brian Parkinson wrote:
> 
>> However, as near as I can tell, there is no difference - in both
>> cases, the message remains in the queue until a consumer comes and
>> retrieves it. Is there a difference in this case?
> 
> If you are not seeing a difference then you are most likely shutting down the broker forcibly without the use of transactions. If you set the channel to transaction mode:
> 
> channel.txSelect();
> 
> and commit after the publish:
> 
> channel.txCommit();
> 
> then you will see persistent messages in durable queues even after an unclean shutdown.
> 
>> Perhaps it's more useful to outline what my use case is - I need to
>> have high availability, and so can form a multi-node broker, but
>> since the queues are (currently) tied to a node, if a node goes down,
>> I lose the queue (and all the messages in that queue). How does one
>> design this setup in RabbitMQ/AMQP - I'm guessing there's a pretty
>> standard pattern here (?).
> 
> For high availability you should look at the Pacemaker guide: http://www.rabbitmq.com/pacemaker.html . This uses persistent storage and a heartbeat mechanism between two brokers.
> 
>> ps. I'm using the whizzy mgmt web front end; when I launch the
>> server, I see some warnings about undefined functions (see below). Is
>> this something I should worry about?
> 
> Those warnings are normal. Mochiweb uses some functions in some modules we don't distribute.  One of our startup checks catches this and complains. Since we never actually use those functions, it shouldn't be a problem.
> 
> 
> Regards
> 
> 
> Emile