Thanks Arvind.� That seems to confirm our belief that rabbitmq doesn&#39;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. <br>
<br>Ideally, I&#39;d like my broker cluster to handle this.� I&#39;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.<br>
<br>