Hi Jack,
This is exactly the kind of use case that Dispatch is intended for.
With regard to reply-to semantics, Dispatch uses AMQP's dynamic-terminus
capability to assign routable addresses for use as reply-to values. By
'routable' I mean that any router in the network will know how to
forward the address back to the requester. There is no configuration
required to make it work.
In terms of the qpid::messaging API, if you create a connection to
Dispatch (you have to use AMQP 1.0), and in that connection create a
receiver from address "#", Dispatch will assign an address that can be
used in the reply-to field of sent messages (you can get the address
using Receiver::getAddress()).
With regard to connection volume, load-balancing, HA, etc... Dispatch
can be deployed in a network of routers to share the load. It is
expected that an ordinary server load balancer can be used to distribute
the connection load across an array of routers. As long as the network
topology is sufficiently redundant, the failure of any router or
inter-router connection can be sustained without losing service.
If you'd like to look at this in greater detail, I'd be happy to discuss
it further.
-Ted
On 10/07/2013 11:45 AM, Gibson, Jack wrote:
Currently, we are using a set of brokers as gateway/routers in order
to distribute work, handle large connection volume, etc. One of the
things that I don't like about this setup is that the routing rules
are pretty cumbersome especially the replyTo semantics. I am
thinking that using the dispatch router would be a much better
solution. Any suggestions?
Jack
Deploy.png
*
*
*
*
