Ted - Let's setup some time this week. I believe I still have your contact information so I'll ping you.
Jack On 10/8/13 8:03 AM, "Ted Ross" <[email protected]> wrote: >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 >> >> * >> * >> >> * >> * >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
