How are NMR flows selected in FUSE ESB?

[mielket]

Looking at the default out-of-the-box FUSE ESB configuration it seems to enable SEDA, JMS and JCA flow all at the same time (inside  in servicemix.xml). Can someone please explain using what criteria one of these flows is selected at runtime? Is a flow selected per container or at a finer granularity, e.g. per deployment?

What happens when e.g. I run a clustered FUSE ESB environment? Is the JMS flow automatically selected? When would it switch to JCA? And finally does changing a flow require a restart?

[bsnyder]

Can someone please explain using what criteria one of these flows is selected at runtime?

Flow selection is the job of the DefaultFlowChooser.chooseFlow() method. This method delegates to each flow's canHandle() method to check various qualities of service on the exchange to determine if the flow can handle that exchange. Below are links to the canHandle() method for each flow:

• JCAFlow.canHandle() method

• AbstractJMSFlow.canHandle() method

• SedaFlow.canHandle() method

Notice that each method checks the qualities of service that are applicable which is where determines of that flow can handle the exchange.

Is a flow selected per container or at a finer granularity, e.g. per deployment?

Flows are selected on a per message exchange basis and is determined by the qualities of service that required by a given exchange.

What happens when e.g. I run a clustered FUSE ESB environment? Is the JMS flow automatically selected? When would it switch to JCA?

When running multiple instances of ServiceMix, the same flow selection process described above is used. Flows are selected based on the qualities of service required by a given message exchange. E.g., if a SU deployed in one instance of ServiceMix needs to send a message to a SU deployed in a different instance of ServiceMix, that remoteness is a quality of service that can only be handled by the JMS flow or the JCA flow.

There is a mapping of qualities of service to flows available in the ServiceMix docs here:

http://servicemix.apache.org/transactions.html

There's also a whole bunch of new info about clustering available in the ServiceMix docs here:

http://servicemix.apache.org/clustering.html

And finally does changing a flow require a restart?

If you change the configuration of a flow in the servicemix.xml, the ServiceMix container needs to be restarted.

[martinmurphy]

Basically a chooseFlow method  is called that checks if a flow is set on the message exchange, if a flow isn't set then it will go through its list of flows (SEDA, JMS and JCA by default) and check to see if it can handle the message exchange. For example the SEDA Flow can't handle clustered messages.

[martinmurphy]

Oops, too quick for me Bruce. I was writing the response while you were posting this more detailed response

[[e-mail]]

So is the order of selection determined by the order that these flows are specified in the servicemix.xml config? Or are you saying that the default order (SEDA, JMS and JCA) is hardcoded somewhere? I'm trying to understand how ServiceMix selects a flow when multiple configured flows all satisfy the QoS requirements.

[bsnyder]

No, the ordering in the servicemix.xml has nothing to do with it. The order is determined simply by the nearest first, i.e., a local flow is selected before a remote flow.

Bruce

[roger]

OK, just to assure that I've understood you right:

Question 1: Even though I configure my container to use the JMS flow (by setting the flowType attribute to for example jms://tcp:61363 or similar), it might happen that ServiceMix decideds to use for example SEDA for transport between two components if they happen reside in the same VM?

Question 2: If I want to enable journaled JMS (perhaps to an external database), thus logging all message exchanges on the NMR, would this mean that I will miss the messages not transported by ActiveMQ/JMS?

Regards,

Roger

[bsnyder]

Question 1: Even though I configure my container to use the JMS flow (by setting the flowType attribute to for example jms://tcp:61363 or similar), it might happen that ServiceMix decideds to use for example SEDA for transport between two components if they happen reside in the same VM?

If the components have the same service name and endpoint, then yes.

Question 2: If I want to enable journaled JMS (perhaps to an external database), thus logging all message exchanges on the NMR, would this mean that I will miss the messages not transported by ActiveMQ/JMS?

I'm sorry I don't understand your question. To what are you referring when you say, '... messages not transported by ActiveMQ/JMS?'

Bruce

[roger]

Hi again,

What I meant was those messages not transported by JMS, i.e. those transported locally one the NMR (using SEDA). I assume these messages won't be processed and journaled by the ActiveMQ instance?

Regards,

Roger

[bsnyder]

Yes, that's correct. The SEDA flow uses java.util.concurrent queues for management of the normalized messages. This has nothing to do with ActiveMQ or JMS.

Bruce

[martinmurphy]

I'm pretty sure that you can get local flows to use JMS queues as well though if you don't make the SEDA flow available to the broker (NMR). For example if I have config like this :

    <sm:broker>
      <sm:securedBroker authorizationMap="#authorizationMap">
        <sm:flows>
          <sm:jmsFlow jmsURL="${activemq.url}"></sm:jmsFlow>
        </sm:flows>
      </sm:securedBroker>
    </sm:broker>

Then the JMS flow would be used for messages since it will be able to satisify all the properties that the SEDA flow could. I haven't tested this though, so correct me if I'm wrong Bruce. This might be useful to persist your messages between components.

[bsnyder]

Yes, that's true, but I'd recommend using the vm protocol instead of the tcp protocol (in the servicemix.properties file) in order to avoid the overhead of the TCP/IP stack on a single machine.

Bruce