<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div>We're moving towards a production deployment of mirrored queues for our platform using RabbitMQ 2.71 on Ubuntu 10.04. One of the things we need to support is rolling upgrades. Thus, while running in a mirrored cluster, we plan to bring down one node at a time while leaving at least one node running.</div><div><br></div><div>The potential problem arises in that our queue client may drain the queue very slowly, e.g., a single message may take hours to execute, and we only process one message at a time per client.</div><div><br></div><div>After completing the maintenance on a node and having it rejoin the cluster, it might be a long time before the queues are synched again. (I'm aware that there's no eager synchronization, and that message synchronization occurs only on message publish.) As a workaround to speed up synchronization, I'm thinking of a small "synchronize now" app that transactionally reads all current messages from the master's queue and republishes them.</div><div><br></div><div>Our code is designed to handle duplicate messages, but we really want to avoid losing messages.</div><div><br></div><div>Questions: Are there any potential pitfalls with this approach? And is there some optimal way to do this that's better than "read/re-publish/ack" for each message in a loop?</div><div><br></div><div>Thanks,</div><div><br></div><div>Matt</div></body></html>