Currently, clustered flows (jms and jca flows) are clustered on a per
component basis. This means that when am exchange is sent from a jbi
container, the routing is performed according to NMR rules : an endpoint
is selected based on the informations provided in the exchange
(endpoint, service and interface). When an endpoint is selected, the
flow retrieves the component that activated the endpoint and sends a
message to a queue (based on the component name).
The main limitation is that all components must have the same endpoints
defined on all nodes of the cluster : if this is not the case, a jms
message could be retrieved by a node, even if the endpoint has not been
activated on this node. Has we currently focus on service unit
deployments, this limitation will shortly become a show-stopper for
clustering.
Another point is that the routing is done by the local node, which
selects an endpoint and assumes all the components across the cluster
will have the same endpoints. So service based routing and interface
based routing do not fit very well in a cluster : if several endpoints
implement one interface, these services can be deployed on different
components, so that selecting an endpoint on the local container will
forbid such kind of routing. The local container is aware of interfaces
implemented by components in other nodes, but load-balancing will not be
effective, as only one component will be selected.
I propose that the clustered flows be enhanced to allow routing /
load-balancing to be effective on all configurations. This simpliest
way would be to define :
* one queue per endpoint (service name + endpoint name)
Optionnaly, we could define
* one queue per service
* one queue per interface
and bypass the endpoint selection in the nmr to delegate it to the flow.
Another problem that comes to mind, is that the nmr will reject any
message if there is no endpoint activated on the cluster : we can not
use the clustered flows to convey messages between two nodes (with the
endpoint only defined on one node) because if the container is
restarted, all messages sent during the time the endpoint is deactivated
will be rejected. So we must either accept it as a limitation, or be
able to make the difference between an endpoint that has been
deactivated because of a restart or a component stop, and an endpoint
that has been deactivated because its service unit has been undeployed.
Note that the current behavior is the same that when using in jvm flows
(st or seda) : messages are rejected.
Any comments ?
Cheers,
Guillaume Nodet
