8 Replies Latest reply on May 21, 2008 1:16 PM by bsnyder

    SEDA and JMS Flow

    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?

       

      What about ST flow?

        • 1. Re: SEDA and JMS Flow
          bsnyder

           

          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

            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

               

              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:

               

              1. Using a JMS flow for communicating amongst JBI components (e.g., servicemix-http, servicemix-bean, etc.) in a cluster of SMX containers

              2. 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

                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

                  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

                    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

                      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

                         

                        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