CODEWITHSUNDEEP
mulemule-studiomule-elmule-component
Star
Star

Reputation: 1503

Mule ESB: How to achieve typical ReTry Mechanism in MULE ESB

I need to implement a logic on Retry. Inbound endpoint pushes the messages to Rest (Outbound). If the REST is unavailable, I need to retry for 1 time and put it in the queue. But the second upcoming messages should not do any retry, it has to directly put the messages in to queue until the REST service is available.

Once the service is available, I need to pushes all the messages from QUEUE to REST Service (in ordering) via batch job.

Questions:

  1. How do I know the service is unavailable for my second message? If I use until Successful, for every message it do retry and put in queue. Plm is 2nd message shouldn't do retry.

  2. For batch, I thought of using poll, but how to tell to poll, when the service becomes available to begin the batch process. (bcz,Poll is more of with configuring timings to run batch)?

  3. Other ticky confuses me is - Here ordering has to be preserved. once the service is available. Queue messages ( i,e Batch) has to move first to REST Services then with real time. I doubt whether Is it applicable.

    It will be very helpful for the quick response to implement the logic.

Using Mule: 3.5.1

Upvotes: 0

Views: 2661

Answers (2)

shzad
shzad

Reputation: 36

I could try something like below: using flow controls

  1. process a message; if exception or bad response code, set a variable/property like serviceAvailable=false.
  2. subsequent message processing will first check the property serviceAvailable to process the messages. if property is false, en-queue the messages to a DB table with status=new/unprocessed
  3. create a flow/scheduler to process the messages from DB sequentially, but it will not check the property serviceAvailable and call the rest service. If service throws exception it will not store the messages in db again but if processes successfully change the property serviceAvailable=true and de-queue the messages or change the status. Add another property and set it to true if there are more messages in db table like moreDBMsg=true. New messages should not be processed/consumed until moreDBMsg=false once moreDBMsg=false and serviceAvailable=true start processing the messages from queue.

Upvotes: 1

seba.wagner
seba.wagner

Reputation: 3870

For the timeout I would still look at the response code and catch time-outs to determine if the call was successful or requires a retry. Practically you normally do multi threading anyway, so you have multiple calls in parallel anyway. Or simply one call starts before the other ends. That is just quite normal.

But you can simply retry calls in a queue that time out. And after x amounts of time-outs you "skip" or defer the retry.

But all of this has been done using actual Mule flow components like either:

One possibility for the queue would be to persist it in a database. Mule has database connector that has a "poll" feature, see: http://www.mulesoft.org/documentation/display/current/JDBC+Transport+Reference#JDBCTransportReference-PollingTransport

Upvotes: 0

Related Questions