|| at Jun 29, 2009 at 9:44 pm
I am not sure if this will completely answer your question but ...http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-February/003359.html
"The node to which a client is connected when it
issues a queue.declare that creates a new queue is the node that the
created queue is situated on until it's deleted and recreated."
Re HA ... it's doable in various ways. A short video about this and
federation is here:http://skillsmatter.com/podcast/cloud-grid/rabbitmq-internal-architecture-tony-garnock-jones
Please *do* tell us more about your problem if the above does not
help. Your approach is sound but managing it optimally over time may
require more info about your use case.
On Mon, Jun 29, 2009 at 1:02 PM, Daniel Lundinwrote:
Still designing something workable for high availability over here. A
workable solution would be to bind multiple queues on different nodes to
the same exchange, hence assuring persistence on multiple locations
while maintaining availability.
This would suffice quite well for my case.
Is there currently a way to ensure that queues are, in fact, created on
different or specific nodes?
Is a queue always created on the node the client connected to before
rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.comhttp://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss