3 Replies Latest reply on May 21, 2008 1:26 PM by bsnyder

    Implementing ServiceMix retry logic?

    roger

      Hi all,

       

      I need some hints on what's best-practice for implementing retry logic for certain components on the ESB. Any information on the topic is welcome, as is any references to further studies.

       

      Let's say we have the following situation:

       

      1. Inbound Binding Component A receives a message from outside and passes it on to a router (e.g. the servicemix-eip component).

      2. The router component, B, analyzes the message content and pipelines the message to binding component D, letting Service Engine C perform some enrichment using a database.

      3. Outbound Binding Component D finally de-normalizes the message and sends it to an external receiver.

       

      During this chain of events, it might happen that something goes wrong. In some of these cases, we want the message to queue up for periodic retries. This might be due to for example the following:

       

      - The database (used by C) is temporarily down

      - The external receiver (D's consumer) is temporarily closed down

      - In case one of the BC's being placed on another ESB instance (inter-connected through), that instance might be down as well

       

      Questions/topics

      1. The ExchangeStatus concept somehow implements this, though I don't know whether that's what the functionality is intended for?

      2. If I want a delay between the retries, would it be possible to configure the ESB to provide that?

       

      Any views on this important issue are welcome!

       

      Regards,

      Roger

        • 1. Re: Implementing ServiceMix retry logic?
          bsnyder

           

          During this chain of events, it might happen that something goes wrong. In some of these cases, we want the message to queue up for periodic retries.

           

           

          In this case I'd recommend using JMS semantics via the use of the servicemix-jms component because JMS provides retry capability already, so there's no reason to implement this in other components.

           

           

          1. The ExchangeStatus concept somehow implements this, though I don't know whether that's what the functionality is intended for?

           

           

          There is no retry logic in the ExchangeStatus object. That object is nothing more than a container for the status of a message exchange.

           

           

          2. If I want a delay between the retries, would it be possible to configure the ESB to provide that?

           

           

          Redelivery can already be controlled through both JMS as well as via the servicemix-camel component. Take a look at these two components.

           

          Bruce

          • 2. Re: Implementing ServiceMix retry logic?
            roger

            Thanks a lot for the answers! With small steps I take myself forward in this jungle...

             

            One further question though: If I activate JMS flow (I suppose I do that by adding the flowType attribute to the container tag in my servicemix.xml file?), would I then use the ActiveMQ settings to control redelivery? I've seen some settings there, but how would I control it per component?

             

            Perhaps this is where Apache Camel comes into question?

             

            Regards,

            Roger

            • 3. Re: Implementing ServiceMix retry logic?
              bsnyder

               

              One further question though: If I activate JMS flow (I suppose I do that by adding the flowType attribute to the container tag in my servicemix.xml file?), would I then use the ActiveMQ settings to control redelivery? I've seen some settings there, but how would I control it per component?

               

               

              The JMS flow is already enabled by default in the servicemix.xml container configuration. Below is the default snippet from that file where the flows are enabled:

               

                  <sm:broker>
                    <sm:securedBroker authorizationMap="#authorizationMap">
                      <sm:flows>
                        <sm:sedaFlow></sm:sedaFlow>
                        <sm:jmsFlow jmsURL="${activemq.url}"></sm:jmsFlow>
                        <sm:jcaFlow connectionManager="#connectionManager"
                                    jmsURL="${activemq.url}"></sm:jcaFlow>
                      </sm:flows>
                    </sm:securedBroker>
                  </sm:broker>
              

               

              Notice that by default, the SEDA flow, the JMS flow and the JCA flow are enabled.

               

               

              Perhaps this is where Apache Camel comes into question?

               

               

              The flows in ServiceMix are used by the NMR to communicate with components via a delivery channel. This has absolutely nothing to do with Camel. Camel is only used in ServiceMix by the servicemix-camel component.

               

              Bruce