-
1. Re: How are NMR flows selected in FUSE ESB?
bsnyder Apr 18, 2008 11:50 AM (in response to mielket)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:
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.
-
2. Re: How are NMR flows selected in FUSE ESB?
martinmurphy Apr 18, 2008 11:57 AM (in response to mielket)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.
-
3. Re: How are NMR flows selected in FUSE ESB?
martinmurphy Apr 18, 2008 11:58 AM (in response to bsnyder)Oops, too quick for me Bruce. I was writing the response while you were posting this more detailed response
-
4. Re: How are NMR flows selected in FUSE ESB?
peterm2@iona.com Apr 29, 2008 11:54 AM (in response to martinmurphy)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.
-
5. Re: How are NMR flows selected in FUSE ESB?
bsnyder Apr 29, 2008 7:03 PM (in response to peterm2@iona.com)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
-
6. Re: How are NMR flows selected in FUSE ESB?
roger May 21, 2008 9:12 AM (in response to bsnyder)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
-
7. Re: How are NMR flows selected in FUSE ESB?
bsnyder May 21, 2008 1:09 PM (in response to roger)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
-
8. Re: How are NMR flows selected in FUSE ESB?
roger May 21, 2008 2:18 PM (in response to bsnyder)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
-
9. Re: How are NMR flows selected in FUSE ESB?
bsnyder May 22, 2008 11:39 AM (in response to roger)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
-
10. Re: How are NMR flows selected in FUSE ESB?
martinmurphy May 22, 2008 12:15 PM (in response to bsnyder)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.
-
11. Re: How are NMR flows selected in FUSE ESB?
bsnyder May 25, 2008 1:22 PM (in response to martinmurphy)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