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>