There is a jira issue for that :
https://jira.logicblaze.com/jira/browse/SM-149
Guillaume
Guillaume Nodet wrote:
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
