Replacing Gateway/Routing Brokers with Dispatch

["Gibson, Jack" <ja...@paypal.com>]

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]

Re: Replacing Gateway/Routing Brokers with Dispatch

["Gibson, Jack" <ja...@paypal.com>]

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" <tr...@redhat.com> 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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Replacing Gateway/Routing Brokers with Dispatch

[Ted Ross <tr...@redhat.com>]

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
>
> *
> *
>
> *
> *
>