Link route rebalancing

["Petrenko, Vadim" <va...@ns.nl>]

Hi all,

I would like to understand better how Link routing works.

I have a Java Qpid JMS client, a Qpid router mesh (4 interior routers + 2 edge) and two Artemis brokers on the other side of the mesh.
I define link routing in the Interior routers using a prefix (so it's not address specific, to make it more flexible), e.g.:

linkRoute {
    prefix: telemetry
    direction: in
}

linkRoute {
    prefix: telemetry
    direction: out
}

Configuration on the edge routers is standard for link routing and everything works.

Now I expect, that when I subscribe to a topic starting with "telemetry." on Artemis, the mesh will determine the optimal path at that moment in time and this specific route will be there until I disconnect.
Is this how it really works? Or can the mesh re-calculate a more optimal route later and change the path of the messages?

This question is primarily because of the following:
Imagine I have 2 clients and 2 brokers. These are Link routing paths as automatically determined by the mesh on the first connect:
(Client 1) -> (Router A) -> (Router B) -> (Router C) -> (Broker 1)
(Client 2) -> (Router D) -> (Router B) -> (Router E) -> (Broker 2)
As you can see both paths intersect at the Router  B.

I start sending a moderate number of messages along the first path, everything works.
Now I start sending a massive number of messages through the second Link routed path. The routers along the path become overloaded, including the Router B.
I would really like to see that the mesh notices this and reroutes messages flowing along the first Linked path using some other Router F, which is free, instead of the overloaded Router B, so that Client 1 doesn’t experience throughput degradation. But this is not possible, or is it?
Another consideration: under heavy load I might want to scale this up and add more routers to the network (new nodes, not new pods). With Link routing this wouldn't seem to make any sense because the path is "set in stone" and cannot be changed, right? I add more Routers G, H, I, etc, but the Router B is still being used without any change.

Could you please comment if I understand this correctly?
Is there any possibility to make Link routing dynamic and re-routable (more or less as message routing)?

Thank you.





________________________________

Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor (gebruik door) de geadresseerde. De e-mail kan persoonlijke of vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail (en eventuele bijlagen) te vernietigen.

Informatie vennootschap<http://www.ns.nl/emaildisclaimer>

Re: Link route rebalancing

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

On 24/02/2021 16:16, Petrenko, Vadim wrote:
> Hi all,
> 
> I would like to understand better how Link routing works.
> 
> I have a Java Qpid JMS client, a Qpid router mesh (4 interior routers + 2 edge) and two Artemis brokers on the other side of the mesh.
> I define link routing in the Interior routers using a prefix (so it's not address specific, to make it more flexible), e.g.:
> 
> linkRoute {
>      prefix: telemetry
>      direction: in
> }
> 
> linkRoute {
>      prefix: telemetry
>      direction: out
> }
> 
> Configuration on the edge routers is standard for link routing and everything works.
> 
> Now I expect, that when I subscribe to a topic starting with "telemetry." on Artemis, the mesh will determine the optimal path at that moment in time and this specific route will be there until I disconnect.
> Is this how it really works? 

Yes. The path to the source- or target- of the route is determined when 
the link is established. Subsequent interaction on that link is 
forwarded over that path.

> Or can the mesh re-calculate a more optimal route later and change the path of the messages?
> 
> This question is primarily because of the following:
> Imagine I have 2 clients and 2 brokers. These are Link routing paths as automatically determined by the mesh on the first connect:
> (Client 1) -> (Router A) -> (Router B) -> (Router C) -> (Broker 1)
> (Client 2) -> (Router D) -> (Router B) -> (Router E) -> (Broker 2)
> As you can see both paths intersect at the Router  B.
> 
> I start sending a moderate number of messages along the first path, everything works.
> Now I start sending a massive number of messages through the second Link routed path. The routers along the path become overloaded, including the Router B.

A single link should not overload a router.

> I would really like to see that the mesh notices this and reroutes messages flowing along the first Linked path using some other Router F, which is free, instead of the overloaded Router B, so that Client 1 doesn’t experience throughput degradation. But this is not possible, or is it?
> Another consideration: under heavy load I might want to scale this up and add more routers to the network (new nodes, not new pods). With Link routing this wouldn't seem to make any sense because the path is "set in stone" and cannot be changed, right? I add more Routers G, H, I, etc, but the Router B is still being used without any change.
> 
> Could you please comment if I understand this correctly?

Yes, what you say is correct.

> Is there any possibility to make Link routing dynamic and re-routable (more or less as message routing)?

The point of link routing is to establish a 'virtual' link between 
sender and receiver, through the router network over which link scoped 
AMQP performatives can be forwarded in either direction. In its current 
implementation there is no way to dynamically route each individual 
performative between the two endpoints.

For more dynamic balancing you need to use message routing.


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