Re: AMQP 1.0, Qpid broker+dispatcher, and routing

[tomt <tt...@netapp.com>]

Gordon,

It looks like the java broker cannot do the wildcarding on the address, but
configuring a topic via qpid-config looks promising.

As far as the naming of topics in the broker, I had asked last time about
dot notation vs slashes since I had read the AMQP 1.0 addressing spec.  Does
it make sense to use slashes in the naming for topics to be inline with the
addressing spec?  

As far as my expected setup goes, I have 4 machines dedicated to my
exploration effort here and I am running the qpid-cpp broker in HA mode.  I
also have a router on each machine that points to the active broker.  In the
event of a broker failover to another node, the router configurations are
expected to be modified on the fly to point to the newly active broker.  My
routers have link routing configured so any topic with a given prefix can be
subscribed to from any machine in my cluster by any number of clients
unknown to me.  I would think the clients would have no idea that anything
changed under the covers but have not yet had a chance to test this.

It looks like this dispatcher config using link routers should work for my
needs over broker messaging unless I'm missing something.  From what I can
tell, in broker messaging you must define the ins and outs for each queue in
qdrouter's configuration where link routing is more flexible by creating the
virtual tunnel you mentioned for the link.  I can even set link options like
timeout, which is important next.

I have seen in the broker that the defined name for the virtual tunnel is
<router_id>:<container_id>@<subscription_name> (or something very close to
that).  If my AMQP client that is connected to one router unexpectedly moves
over to another router, can it attach to the existing link on the new router
(if the router names are all the same)?

Any thoughts or concerns?

Thanks,
Tom



--
Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: AMQP 1.0, Qpid broker+dispatcher, and routing

[Gordon Sim <gs...@redhat.com>]

On 07/01/2020 5:01 am, tomt wrote:
> As far as the naming of topics in the broker, I had asked last time about
> dot notation vs slashes since I had read the AMQP 1.0 addressing spec.  Does
> it make sense to use slashes in the naming for topics to be inline with the
> addressing spec?

It doesn't make any difference to qpid-cpp (or the router).

> As far as my expected setup goes, I have 4 machines dedicated to my
> exploration effort here and I am running the qpid-cpp broker in HA mode.  I
> also have a router on each machine that points to the active broker.  In the
> event of a broker failover to another node, the router configurations are
> expected to be modified on the fly to point to the newly active broker.  My
> routers have link routing configured so any topic with a given prefix can be
> subscribed to from any machine in my cluster by any number of clients
> unknown to me.  I would think the clients would have no idea that anything
> changed under the covers but have not yet had a chance to test this.
> 
> It looks like this dispatcher config using link routers should work for my
> needs over broker messaging unless I'm missing something.  From what I can
> tell, in broker messaging you must define the ins and outs for each queue in
> qdrouter's configuration where link routing is more flexible by creating the
> virtual tunnel you mentioned for the link.  I can even set link options like
> timeout, which is important next.

Agreed, link routing is what you want for an arbitrary number of 
independent topic subscriptions.

> I have seen in the broker that the defined name for the virtual tunnel is
> <router_id>:<container_id>@<subscription_name> (or something very close to
> that).  If my AMQP client that is connected to one router unexpectedly moves
> over to another router, can it attach to the existing link on the new router
> (if the router names are all the same)?

I don't think the router names *can* be the same, as they need to be 
uniquely identified. For durable (or reliable) subscriptions, that will 
indeed likely pose a problem, not from where the client is attached but 
from which router is connected to the broker (as it is the container id 
of that router that the broker will see).

You can set a 'shared' capability on the link source, in which case the 
c++ broker will use only the link name (not qualified by the container id).


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org