I suggest we handle all of these valid points as options (there all
straightforwarrd to support). Another thing is there a need for the
JMS Flow ? Can't we just support the JCA Flow - there's not much
difference between the two.
cheers,
Rob
On 24 Nov 2005, at 12:51, 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
