A {@link RoutingStrategy} is responsible for determining how to find the appropriateNode within a given cluster given a {@link MessageKey}. It has both an {@link Inbound}side and an {@link Outbound} side that work together using the {@link MpCluster} todo the bookkeeping necessary.
A simple example would be: a non-elastic, fixed-width cluster {@link RoutingStrategy} thatsimply selects the Node to send a message to based on the mod ('%' operator) of the hash of a message's key with the number of nodes in the cluster.
In this example the {@link Inbound} strategy, which would be instantiated in each node,would be implemented to register the its current Node with the {@link MpCluster}. The {@link Outbound}side would use the registered information to select the appropriate Node.
As mentioned, RoutingStrategy implementations need to be balanced. The {@link Inbound} cansafely assume that the {@link Outbound} created from the same strategy was responsible for setting up the cluster.
{@link Inbound} and {@link Outbound} need to be thought of in terms of the stages of apipeline in a Dempsy application. E.g.:
Adaptor --> inbound1|Stage1|outbound2 --> inbound2|Stage2|outbound3 ... Notice that outbound2 and inbound2 require coordination and are therefore defined in the {@link ApplicationDefinition} using a single {@link RoutingStrategy} aspart of the {@link ClusterDefinition} that defines Stage2
As an example, the DecentralizedRoutingStrategy's Inbound and Outbound coordinate through the cluster. The Inbound side negotiates for slot ownership and those slots contain enough information for the Outbound side
Implementations must be able to handle multi-threaded access.
| |