Jiri<div><br></div><div>Thank-you for bringing this up.</div><div><br></div><div>I have two (initial) questions:</div><div><br></div><div>1. How will out-of-order behaviour be observed in your use case?</div><div><br></div>
<div>2. Do you plan to use shared queues, or will each queue have just one consumer client so that all pubsub happens using the exchange? �</div><div><br></div><div>Best wishes</div><div><br></div><div>alexis</div><div><br>
</div><div><br></div><div><br><br><div class="gmail_quote">On Thu, Sep 2, 2010 at 4:09 PM, <span dir="ltr"><<a href="mailto:jiri@krutil.com">jiri@krutil.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello together<br>
<br>
We are considering an active-active high availability broker setup and I wanted to check if there is someone here who could help with experience/advice.<br>
<br>
We plan to run two RabbitMQ brokers with the same setup (same queues, exchanges, bindings), which are independent and not aware of each other. These would be behind a load balancer, so this should be transparent to client applications.<br>
<br>
We use AMQP for two things:<br>
- pub/sub broadcasts from back-end to clients (all clients bind to the same topic exchange)<br>
- P2P request-response, where back-end responds to client requests (all clients send to the same request queue)<br>
<br>
We have only one back-end server that serves the clients. Of course the back-end would have to publish broadcasts to and consume requests from both brokers.<br>
<br>
When one broker dies, the clients will re-connect via load balancer to the other broker and continue. Of course any messages on the dead broker will be lost. We don't use persistent messages and can live with messages being lost.<br>
<br>
So far I have only identified one problem - the order of message delivery across brokers. Since the design of our client-server interface relies on the guaranteed order of message delivery, we would probably have to force clients to put request sequence numbers to message headers, remember the last seen request number on the back-end for each client, and throw away any requests out of order.<br>
<br>
Any ideas or hints will be much appreciated.<br>
<br>
Cheers<br>
<br>
Jiri<br>
Deutsche Boerse Systems AG<br>
<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</blockquote></div><br></div>