Rob Springer wrote:
All - we are considering using federation to ease
some of the load on our broker, but before starting that work, we had
a few questions about how message reliability intersects with
federation. We lean heavily on ACCEPT_MODE_EXPLICIT to ensure
reliability in case of a fault in our applications, and so losing
reliability in favor of scalability isn't a win for us. So...our
questions:
- Does using federated exchanges change the semantics of message
transfer (if the link and any relevant queues are durable, etc.)?
- In case of Qpid termination, will the BDB store recover in a
federated environment just as in a non-federated one?
In general, I suppose our questions can be summed up as "Do the steps
or techniques required for reliable (and acknowledged) message
transfer change in any way when using federation?"
Thanks, everyone!
-Rob
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
Hi Rob,
Qpid broker federation uses normal AMQP message transfer semantics for
inter-broker communication. When setting up a queue route (i.e.
configuring one broker to consume messages from a specific queue on
another broker) using the "qpid-route queue add <dest-broker>
<src-broker> <exchange> <queue>" command, there is a command line option
called "--ack" which controls the way messages are transferred between
the brokers. If --ack is not supplied, the inter-broker subscription
uses accept-mode:none. If an ack value is supplied, the subscription
uses accept-mode:explicit and acknowledgements are sent every N messages
where N is the number supplied in the --ack option.
If the queues in question are durable and the federation route is
durable, the federated set of brokers should recover cleanly after the
restart of one, several, or all of the brokers.
-Ted
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
