Thanks Gert, this is really helpful
Gert Vanthienen wrote: > > 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. >> >> > > > ----- > --- > Gert Vanthienen > http://gertvanthienen.blogspot.com > -- View this message in context: http://www.nabble.com/camle-jbi-component-and-flow-tp23749187p23754597.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
