Enterprise Integration Zone is brought to you in partnership with:

Enterprise Architect, appointed Mule ESB Champion. Tomas is a DZone MVB and is not an employee of DZone and has posted 4 posts at DZone. You can read more from them at their website. View Full User Profile

Mule and Quartz – Scheduled Jobs and Long Running Tasks

03.06.2013
| 4483 views |
  • submit to reddit

Recently I had a situation where I needed to get confirmations from an external system (webservice) at frequent intervals and add them to a database. All available confirmations were retrieved in a batch when the service was invoked. A confirmation was sent to the Service after a successful retrieval.

Of course, came to mind. Piece of cake I thought and implemented the scenario using Mule ESB. Everything seemed to work as planned until we started to notice duplicates of confirmations in the database. After some investigation it turned out that occasionally there were thousands of confirmations retrieved and inserted into the Database. Since inserting thousands of records took longer time than the scheduled interval, a new request for confirmations was made before the retrieval process could complete.

So how do we prevent this?

First of all we have to make the quartz connector thread pool only hold one thread, otherwise a new thread could start the same job even though an active job is running.

This is easily done:

<quartz:connector name="myQuartzConnector" validateConnections="true">
  <receiver-threading-profile maxThreadsActive="1"/>
</quartz:connector>

Is that enough? No, since Mule is so well designed, all message processors has it’s own thread pool so even if Quartz only serves one thread that one appears to be finished when the next message processor in the flow takes over. Since that processor has it’s own thread pool it can handle multiple jobs coming from Quartz.

So what we need to do is to make sure that the whole flow is using the same thread all the way through. This is easily achieved using processingStrategy:

<flow name="GetConfirmationsFlow" processingStrategy="synchronous">
  <quartz:inbound-endpoint cronExpression="${my.cronExpression}" jobName="confirmations" connector-ref="myQuartzConnector">
    <quartz:event-generator-job>
      <quartz:payload file="ConfirmationsSOAPRequest.xml" />
    </quartz:event-generator-job>
  </quartz:inbound-endpoint>
  <http:outbound-endpoint address="${get.confirmations.adress}" method="POST" exchange-pattern="request-response">
  <!-- A lot of transformation and splitting, not interesting for this -->
  <http:outbound-endpoint address="${confirm.retrieval.adress}" method="POST" exchange-pattern="request-response">
</flow>

Setting the processingStrategy to synchronous makes sure that one thread is used through out the flow and Quartz can’t create a new one before that one is finished.

No more duplicates…

No related posts.

Published at DZone with permission of Tomas Blohm, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Zanya Arte replied on Wed, 2013/09/04 - 4:04am

If you routine work within Microsoft windows, you might be encoding the item to open a credit card applicatoin or maybe file, deliver a contact or maybe perform any screenplay over a selected night out and for a distinct occasion. You'll be able to routine work that occur daily, regular, regular monthly, 1 time or maybe after having a specific function. jobs germany 

Zanya Arte replied on Wed, 2013/09/04 - 4:06am

If you routine work within Microsoft windows, you might be encoding the item to open a credit card applicatoin or maybe file, deliver a contact or maybe perform any screenplay over a selected night out and for a distinct occasion. You'll be able to routine work that occur daily, regular, regular monthly, 1 time or maybe after having a specific function. jobs germany  

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.