Alan,
I like your ideas about simplifying waypoint configuration. I think
that in the most common use cases for waypoints, a much simpler
structure is appropriate. I also like the idea of a centralized concept
(not sure "relay" is the right name) to capture the essence of
message-routing-to-intermediaries and link-routing. In a separate
reply, I'll show what's happening on the core-refactor development branch.
I'll wait to hear your ideas about more general address-rewriting, but I
will say that as a core principle, we need to be concerned about the
lookup scale and performance for addresses.
Dispatch currently uses a combination of address normalization and a
hash table lookup to ensure fast lookups for a large number of
addresses. A generalized match-and-rewrite might not meet these criteria.
-Ted
On 02/23/2016 10:40 AM, 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": {...}
"connector": {...}
}
}
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.
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.
(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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
