On 02/25/2016 04:21 PM, Gordon Sim wrote:
On 25/02/16 21:18, Ted Ross wrote:
On 02/25/2016 03:57 PM, Alan Conway wrote:
- if you need separate in/out treatments, split the waypoint into a
source/sink pair for the same address. That is less confusing because
the "half-route" only has one message flow direction so no need for
inFoo/outFoo. It makes the config a little more verbose but this is a
complex use case.
I prefer the second for clarity and future-proofing. It means we can
add future options that might be set differently for inbound/outbound
without multiplying inFoo/outFoo, inBar/outBar on the route.
This makes sense to me. It significantly reduces the number of
attributes of a route and still keeps the most common cases simple.
I agree.
Here's my earlier cut with updates based on some of Alan's and Gordon's
suggestions: Note that I've kept "treatment" in place but would happily
replace it with something better.
For direct messaging between producers and consumers:
Direct multicast delivery (one copy to every subscriber to the address):
route {
address: service.mcast
path: direct
treatment: multicast
}
Direct delivery to only the closest (lowest cost) subscriber:
route {
address: service.regional
path: direct
treatment: closest
}
Direct delivery to one subscriber favoring subscribers that settle
deliveries more quickly.
route {
address: service
path: direct
treatment: balanced
}
For messaging involving a queue, topic, or other intermediate process.
In these cases, the remote container may be identified by container-id
or connection label (container-id shown in examples):
Link-routing to a queue:
route {
address: my_queue
path: waypoint
treatment: linkBalanced
container: [<broker-container-id>]
}
Link-routing only for enqueue:
route {
address: my_queue
path: sink
treatment: linkBalanced
container: [<broker-container-id>]
}
Link-routing only for dequeue:
route {
address: my_queue
path: source
treatment: linkBalanced
container: [<broker-container-id>]
}
Simple queue waypoint (treatment defaults to 'balanced'):
route {
address: my_queue
path: waypoint
container: [<broker-container-id>]
}
Topic waypoint that supports selectors:
route {
address: my_topic
path: sink
treatment: multicast
container: [<broker-container-id>]
}
route {
address: my_topic
path: source
treatment: linkBalanced
container: [<broker-container-id>]
}
Distributed (sharded) queue waypoint:
route {
address: my_queue
path: waypoint
container: [<broker-1-container-id>, <broker-2-container-id>]
}
Distributed (sharded) topic waypoint:
route {
address: my_topic
path: sink
treatment: multicast
container: [<broker-1-container-id>, <broker-2-container-id>]
}
route {
address: my_topic
path: source
treatment: linkBalanced
container: [<broker-1-container-id>, <broker-2-container-id>]
}
=====================================================================
Syntax:
route: {
path: direct | source | sink | waypoint
address: (address or prefix)
treatment: multicast | closest | balanced | linkBalanced
connector: (list: label of a connection to/from a remote container)
container: (list: ID of a connected remote container)
routeAddress: (address to use in route table lookup, if different)
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
