L.S., You can control the flow used by the broker by adding the "org.apache.servicemix.flow" (JbiConstants.FLOW_PROPERTY_NAME) to the Exchange properties with the name of the flow as a value. However...
Because of exactly this problem, the JMS/JCA flows being all-or-nothing and causing overhead by sending every single exchange through JMS, we often recommend people to use explicit JMS endpoints instead of relying on the flows for QoS/persistence. After all, it is the underlying broker that provides the cluster functionality and not our flows. There is a slight overhead in having to configure the additional JMS endpoints, but on the other hand this approach offers you a lot more flexibility and it allows you to fine-tune transactional boundaries, persistence requirements, JMS versus Seda messaging, ... Personally, if I read your requiremens, I would definitely recommend you to use the explicit JMS endpoints approach, just configure the container to use Seda flow for performance and add the JMS endpoints to provide the QoS/clustering/persistence where you need it. Regards, Gert Vanthienen ------------------------ Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/5/27 javadevel <[email protected]>: > > JB, > > Thank you so much for your quick response, I realize that SEDA is an in > memory map that can only be used internally and will not be available to > components that are not deployed on the same smx instance. The thing is the > camel JBI router we have gets the message from the NMR and sends the message > to other components via the NMR but while the message is inside its local > router, it uses SEDA for purposes of simplicity. We are fully aware that > things that are put on the SEDA queue will not be accessible to other > components in the cluster and we don’t expect them too. What we wanted to do > was to use SEDA for the local route by explicitly requesting SEDA for > specific internal communication and use the JMS flow when the request goes > back out to the NMR. Let me know if my assumption is incorrect and if SMX > only uses the flow specified on the servicemix.xml regardless. > > > Jean-Baptiste Onofré wrote: >> >> Hi, >> >> Regarding that you describe, you use ServiceMix 3. >> >> I guess your conf/activemq.xml file contain transporterConnectors >> definition and a persistenceAdapter like this: >> >> <amq:transportConnectors> >> <amq:transportConnector uri="tcp://localhost:61616"/> >> </amq:transportConnectors> >> >> <amq:persistenceAdapter> >> <amq:journaledJDBC journalLogFiles="5" >> dataDirectory="/<shared>/data/amq"/> >> </amq:persistenceAdapter> >> >> >> (maybe you use a persistenceAdapter backend different from JDBC adapter). >> >> ServiceMix supports the following flow: >> - straught-through (ST) >> - seda >> - JMS >> - JCA >> >> A JMS flow is used for cases where you need collaboration between more >> than one ServiceMix JBI container. For example, an application that >> needs to have fail-over capability or an application that needs to >> balance its endpoints among several machines would need to have one or >> more JBI containers working in concert. >> When JBI containers are deployed in a cluster, component deployment >> happens in the same way as a normal, but all the containers in the >> cluster are notified of a deployment, and the JMS flow handles automatic >> routing and failover of MessageExchange(s) between the container >> instances. >> A Message Queue is used for each JBI endpoint, so multiple instances of >> the same named Component will have requests load balanced across them. >> >> JCA flow is very similar to the JMS one and can be used to cluster >> ServiceMix containers together. >> >> So, to summarize, if you need to cluster ServiceMix containers, you have >> to use JMS or JCA flow, SEDA is not supported directly for clustering. >> >> Regards >> JB >> >> javadevel wrote: >>> We have a clustered servicemix instances that only have JMS flow enabled. >>> We >>> routing logic that is implemented using the camel JBI component that, for >>> some simple cases, uses SEDA as a choice of communication between >>> internal >>> endpoints. However, the explicit use of SEDA as part of the camel JBI >>> component causes an error to be generated and the entire request to fail. >>> We >>> changed the servicemix instance configurations to allow both JMS and SEDA >>> flow but this caused all communications to go over SEDA and this defeats >>> the >>> purpose of having a clustered environment. Is it possible to configure >>> SMX >>> in such a way that it would use JMS as a default flow and uses SEDA if >>> explicitly required? >>> >>> Thanks >> >> -- >> Jean-Baptiste Onofré (Nanthrax) >> BuildProcess/AutoDeploy Project Leader >> http://buildprocess.sourceforge.net >> [email protected] >> PGP : 17D4F086 >> >> > > -- > View this message in context: > http://www.nabble.com/camle-jbi-component-and-flow-tp23749187p23750142.html > Sent from the ServiceMix - User mailing list archive at Nabble.com. > >
