[rabbitmq-discuss] rabbitmq cluster failover for persistent queues

[Alexis Richardson]

Charles

Thank-you very much for your questions.  (And Arvind, thanks for
answering them!).

Can you clarify what you mean by "failover of session state" please?
I am assuming you mean that when a node dies, then another node can
'take over' from it, without loss of any state that the first node has
committed (to some other node and/or persistent store), and that the
second node can 'take over' in some sense 'faster' than recovery by
restarting the first node from disk would.  I ask because this case is
not quite the same as 'exactly once' delivery.

Cheers,

alexis





On Sun, Jul 26, 2009 at 6:45 PM, charles
woerner<charleswoerner.lists at gmail.com> wrote:
> Thanks Arvind.  That seems to confirm our belief that rabbitmq doesn't
> handle failover of session state at the moment.  So in the case of competing
> consumers taking messages from a rabbitmq broker cluster it sounds like
> once-and-only-once delivery is somewhat up to the application to implement
> by arranging for each message to be delivered to redundant queues (ie. 2
> separate queues with similar bindings residing on different hosts), then
> coordinate among your consumers to ensure once-and-only-once delivery using
> a database or simply to make your workflow idempotent with respect to the
> duplicate messages.
>
> Ideally, I'd like my broker cluster to handle this.  I'm looking into apache
> qpid as it seems to be more mature with respect to availability.  The main
> downside with rabbitmq for me right now is the lack of at least an option
> for session state replication.  It sounds like a future release of rabbitmq
> with pluggable persisters will make distributed session state possible via
> mnesia.
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>