[rabbitmq-discuss] Examining Queue Failover Behavior

[Dmitriy Samovskiy]

Ben Hood wrote:
> completely transparent to a client is not addressed. The modus
> operandi is to a) not lose messages and then b) give somebody the
> tools to recover a node. The reason why transparent failover has not
Speaking about tools. How doable/easy/difficult would it be to develop a tool to inspect 
and/or replay persister log outside of the broker's erlang vm? Maybe not all of it but 
only basic.publish methods. Such tool would be shipped with broker but will run as a 
standalone process launched by user on demand.

With such tool, if a node crashes, one can get persister log, move it out of mnesia dir, 
wipe out mnesia dir, start rabbit (which will recreate clean mnesia and persister log and 
will get back in business quickly) and then essentially resend all messages that have been 
sent and/or have been sent but have not been acked, or something along these lines.

And, down the road, such tool might offer some sort of filtering support (I am thinking 
something like tcpdump's filtering language) to match against message headers and things 
like publisher's IP, exchange, routing key, time when it arrived, etc.

Thoughts?