-
1. Re: SEDA and JMS Flow
bsnyder Dec 19, 2007 1:03 PM (in response to patrickmulligan)The JMS flow states: "A Message Queue is used for each JBI endpoint, so multiple instances of the same named Component will have requests load balanced across them."
Is this true for SEDA flow? Without looking at the code yet, but I would assume yes?
The quote above is for the servicemix-jms component. It has nothing to do with the flows in ServiceMix. Each flow is implemented separate from each component.
The SEDA flow is an implementation of the SEDA pattern in order to allow scalability at the flow level. There are no JMS queues used in the SEDA flow; only java.util.concurrent queues.
What about ST flow?
The same is true for the ST flow. However, the ST flow has no buffering whatsoever (i.e., no java.util.concurrent queues at all). So the SEDA flow will easily outperform the ST flow.
Bruce
-
2. Re: SEDA and JMS Flow
patrickmulligan Dec 19, 2007 5:55 PM (in response to bsnyder)Thanks Bruce - this is the full snip from the smx docs online at apache at http://servicemix.apache.org/nmr-flows.html:
"A JMS Flow is used for cases where you need collaboration between more than one ServiceMix JBIContainer (for fail-over or scalability).
Component deployment happens in the same way as a normal SericeMix JBI container (both for POJO and archive Component deployment) but all the containers in the cluster are notified of a deployment, and the JMS Flow will handle 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."
So this is a bit confusing?
-
3. Re: SEDA and JMS Flow
bsnyder Dec 20, 2007 1:16 AM (in response to patrickmulligan)Thanks Bruce - this is the full snip from the smx docs online at apache at http://servicemix.apache.org/nmr-flows.html:
"A JMS Flow is used for cases where you need collaboration between more than one ServiceMix JBIContainer (for fail-over or scalability).
Component deployment happens in the same way as a normal SericeMix JBI container (both for POJO and archive Component deployment) but all the containers in the cluster are notified of a deployment, and the JMS Flow will handle 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."
So this is a bit confusing?
Well, it's talking about two distinct types of JBI artifacts and two distinct uses of JMS:
Using a JMS flow for communicating amongst JBI components (e.g., servicemix-http, servicemix-bean, etc.) in a cluster of SMX containers
Using a JMS queue for each JBI endpoint (e.g., SUs that configure JBI components)
They're both using JMS queues but the use cases are unique.
Bruce
-
4. Re: SEDA and JMS Flow
gnodet_gnodet Jan 23, 2008 2:52 AM (in response to patrickmulligan)Actually, there are even more JMS queues involved when using the JMS flow:
one queue per endpoint
one queue per component
one queue per container
SEDA and ST flows do not use JMS at all, but there is one "memory" queue for each component in the SEDA case.
-
5. Re: SEDA and JMS Flow
roger Apr 23, 2008 4:04 AM (in response to gnodet_gnodet)Hi,
Just to be sure: The embedded ActiveMQ is not even used in case of the ST and SEDA flows? Does this mean that a SEDA flow Message Exchange is not persistent or will be durable in a JMS-queue-fashion?
If you could help me to clarify this issue, I would be more than happy!
Regards,
Roger
-
6. Re: SEDA and JMS Flow
martinmurphy Apr 23, 2008 10:07 AM (in response to roger)Correct Roger, ActiveMQ broker is not used for ST and SEDA flows. ST flows run straight through the ESB without any staging, and SEDA flows use the java.util.concurrent classes for staging. Only the JMS and JCA flows provide support for persistent message exchanges.
-
7. Re: SEDA and JMS Flow
roger May 21, 2008 9:37 AM (in response to martinmurphy)Martin, et al,
I've learned that using JMS has a lot of advantages, one of them being that I can use the journaling features of ActiveMQ, optionally even to a database.
However, does this implicate that if I activate the JMS flows, everything will go over the JMS, i.e. ActiveMQ, broker? I've learnt that ServiceMix will choose simpler flow type in certain cases, e.g. SEDA if the components happen to reside in the same VM.
What are your thoughts?
Regards,
Roger
-
8. Re: SEDA and JMS Flow
bsnyder May 21, 2008 1:16 PM (in response to roger)I've learned that using JMS has a lot of advantages, one of them being that I can use the journaling features of ActiveMQ, optionally even to a database.
However, does this implicate that if I activate the JMS flows, everything will go over the JMS, i.e. ActiveMQ, broker? I've learnt that ServiceMix will choose simpler flow type in certain cases, e.g. SEDA if the components happen to reside in the same VM.
What are your thoughts?
As I stated in another discussion thread, the JMS flow is enabled by default. The JMS flow is only used to communicate remotely with components that are deployed in another ServiceMix instance. The JMS flow will not be used to communicate with components deployed to the local ServiceMix instance, the SEDA flow is used for local communications.
Bruce