qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aconway <acon...@redhat.com>
Subject Re: Waypoints and phases in Dispatch Router
Date Fri, 20 Nov 2015 16:54:04 GMT
On Fri, 2015-11-20 at 04:03 +0000, Noel OConnor wrote:
> Thanks guys, I think this explains it nicely but I'll play around
> with
> waypoints some more to ensure I fully understand it. Having read your
> description I think that it's a nomenclature issue.
> To me prefixing "waypoints" and "phases" with "processing" i.e.
> processing
> phases and processing waypoints makes them clearer in my mind.
> Cheers
> Noel

I wrote a user description of the waypoint functionality substituting
"FOO" for waypoint to try to see what word would fit.


A FOO forwards messages between dispatch and an external AMQP process.
The connection can be established in either direction, the FOO can
create multiple sender and/or receiver links to addresses in the
external process.

For example suppose you want a queue on an external broker to appear as
the dispatch address 'myqueue'. You would configure a FOO from address
'myqueue' to create sender and receiver links to the broker queue.

When dispatch receives a message for 'myqueue' it goes to the FOO,
which forwards it to the external broker queue. The FOO "consumes" the
message, it is *not* routed to dispatch network subscribers of
'myqueue'. Instead, when the FOO receives a message from its external
queue subscription, *that* message is forwarded to dispatch
subscribers. The relationship (if any) between messages out and
messages in on the bridge is controlled by the external process.

This means you can use arbitrary external processes (provided they
speak AMQP) to queue, filter, transform or otherwise manipulate
messages sent via a dispatch address.

In advanced cases, FOO's can be chained to so a message passes through
multiple external processes before it is finally sent to dispatch


I think FOO=bridge works pretty well, any other ideas?


The non-chained case does not require any phase configuration, it
should be the default (equivalent to in-phase=0, out-phase=255)

{ waypoint: address=myqueue; connector=broker }

Address rewriting: waypoints and link-routes need to derive external
addresses from internal ones. They are inconsistent (fixedAddrss,
prefix etc.)  We should make address-rewriter an entity and re-use it
for all such needs. address-rewriter should provide options like
strip/add prefix/suffix, hard-coded X->Y mappings and maybe pattern

Chaining: Using integer phases for chaining allows implied fan-out and
fan-in which I'm not sure was intended or makes sense. I suggest we
give chained waypoints explicit names or internal addresses to refer to
each other. I have a feeling that we can generalize "address chaining"
beyond waypoints but not sure how yet.

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

View raw message