Regarding the distributed/sharded cases...
I prefer a syntax that allows a list of containers/connections on a
single route. The issue with that is that adding and removing
containers (a common use case) is not well supported.
Here's a possible solution:
When creating a route, provide an initial list of containers/connections
to be used. This list cannot be directly updated via management.
Add the following methods on the "route" entity to manage the container
list:
ADD_CONTAINER
Expands the capacity by adding a container to the list.
REMOVE_CONTAINER_CLEAN
Cleanly removes a container from the list by first quiescing its traffic
then removing it. Quiescing involves stopping the forwarding of new
messages to the node-on-container and/or waiting for it to be drained.
This ensures that no messages are lost in the transition.
REMOVE_CONTAINER_HARD
Remove the container without quiescing.
-Ted
On 02/24/2016 04:06 PM, Ted Ross wrote:
<SNIP>
Distributed (sharded) queue waypoint:
route {
address: my_queue
type: waypoint
container: <broker-1-container-id>
}
route {
address: my_queue
type: waypoint
container: <broker-2-container-id>
}
Distributed (sharded) topic waypoint:
route {
address: my_topic
type: waypoint
inTreatment: multicast
outTreatment: linkBalanced
container: <broker-1-container-id>
}
route {
address: my_topic
type: waypoint
inTreatment: multicast
outTreatment: linkBalanced
container: <broker-2-container-id>
}
<SNIP>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
