On 23/02/16 15:40, Alan Conway wrote:
I have updated my thoughts on waypoint/link-route config, here's a
sketch. I'm proposing to replace waypoint and linkRoutePattern with a
single "relay" entity. I suggested "bridge" before but I like "relay"
better. It is less over-used and I think it is clearer to say we
"relay" messages or links to/from external AMQP entities than to say we
"bridge" them. It is part of a larger address-rewriting scheme I have
in mind but is useful independnetly for improving waypoint
configuration. I'm still not happy I have address-rewriting figured
out, I will post something soon.
"relay" {
"description": "Relay messages to an external entity using
either link or message routes. Replaces waypoint and linkRoutePattern."
"attributes": {
"relayType": {
type: ["link", "message"]
}
# Following have same meaning as linkRoutePattern
"prefix": {...}
"dir": {...}
Does 'dir' mean direction? If so I think the full word would be clearer.
(On the other hand 'relayType' could probably safely just be 'type').
Would relay elements be uniquely identified by the combination of prefix
and direction?
"connector": {...}
On a related point, I would like to see some way of associating a
'container' (in the AMQP 1.0 sense) with a relay, not just a connector.
That way they would work even if it is the external process that
connects to the router.
}
}
NOTES:
With "relayType"="link" this is exactly the same as present
linkRoutePattern config.
With "relayType"="bridge" we are using the a 'prefix' for waypoints
just like for link-routes. There's no reason to use different solutions
for each.
Is the type here 'message' or 'bridge'?
I will expand on prefix matching in my address-rewriting proposal to
allow more complex forms of pattern matching (e.g. wildcard, regex) and
substitution to generate replacement addresses. Whatever match/replace
features we implement will apply uniformly to link and message relays
as well as enabling multi-tennant and general purpose network-internal
redirects.
We have lost waypoint phases: There isn't a real use-case for them
phases yet and address-rewriting will provide a better solution. Also
"dir" would be ignored by message-relays for now, but will have meaning
with rewriting to restore the phase functionality.
Why would dir be ignored for now? Perhaps I'm not understanding how you
intend these relays to be used to effect the behaviour we currently use
waypoints for, i.e. to route messages from producers attached to the
router network, through a broker queue, and back out to consumers
attached to the router network.
I had assumed this would involve two relays with the prefix set to the
name of the queue, and each direction covered.
(Hint: internally waypoint phases *are* simple address rewriting rules.
They effectively add a hidden "phase" prefix to the address. However
that prefix is hidden as "special waypoint magic" and can't be used for
anything else. I propose to make it part of a uniform address-rewriting
mechanism that can be used by any of our routing modes as well as for
multi-tennant and other types internal redirection. When we do that,
the "dir" parameter combined with rewrite rules will give us back
"inPhase" and "outPhase" but in a uniform way that can be used by any
type of routing, not just waypoints.)
The relay config is just a subset of existing linkRoutePattern/waypoint
config, so it will be easy to maintain the old config for backwards
compat for a while. The new address rewriting features would be added
to relay, so users would need to update their config to use them, which
shouldn't be too hard.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
