Using Mule EE Retry Policies

At a project for one of our customers we migrated from Mule CE to Mule EE edition (version 2.2.7). The customer had various good reasons to do this and it offered us new functionalities in Mule ESB to use. One of those ‘new’ things is RetryPolicy for some of the Mule Connectors. I quoted ‘new’ because there is also an open source variant that you can use in the community edition but since the customer paid for it I wanted to use this version that comes with Mule EE out-of-the-box.
To make use of this EE version I performed the normal steps that you would do when you add a new module to you (Maven) Mule project (as I described here). So in short:

  • Add the namespace to the Mule config:

    <mule xmlns="http://www.mulesource.org/schema/mule/core/2.2"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:ee="http://www.mulesource.org/schema/mule/ee/core/2.2"
             xsi:schemaLocation="http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd
           http://www.mulesource.org/schema/mule/ee/core/2.2 http://www.mulesource.org/schema/mule/ee/core/2.2/mule-ee.xsd">
    
  • Add the dependencies to the pom.xml:

    <dependency>
      <groupId>com.mulesource.muleesb</groupId>
      <artifactId>mule-core-ee</artifactId>
      <version>2.2.7</version>
    </dependency>
    <dependency>
      <groupId>com.mulesource.muleesb.modules</groupId>
      <artifactId>mule-module-retry-ee</artifactId>
      <version>2.2.7</version>
    </dependency>
    
  • Add the retry-element to the connector:

     <jms:activemq-connector name="JMSConnector" specification="1.1" dynamicNotification="true"
                                brokerURL="failover:(${jms.jndiProviderUrl})"
                                acknowledgementMode="AUTO_ACKNOWLEDGE"
                                maxRedelivery="3"
                                disableTemporaryReplyToDestinations="true"
                                username="${jms.activeMQUser}"
                                password="${jms.activeMQPassword}"
                                persistentDelivery="true">
            <ee:retry-forever-policy frequency="30000"/>
        </jms:activemq-connector>
    

Unfortunately, this seemed not enough since I was getting the following stacktrace:

ERROR 2010-12-22 11:55:34,467 [main] org.mule.config.spring.SpringXmlConfigurationBuilder: Configuration with “org.mule.config.spring.SpringXmlConfigurationBuilder” failed.
org.mule.api.lifecycle.InitialisationException: Initialisation Failure: Configuration problem: Failed to import bean definitions from URL location [classpath:config/rs-global-config.xml]
Offending resource: URL [jar:file:/Users/pascal/.m2/repository/nl/redstream/framework/rs-test-unit/2.3-SNAPSHOT/rs-test-unit-2.3-SNAPSHOT.jar!/config/rs-core-test-config.xml]; nested exception is org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 70 in XML document from class path resource [config/rs-global-config.xml] is invalid; nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.a: Invalid content was found starting with element ‘ee:retry-forever-policy’. One of ‘{“http://www.mulesource.org/schema/mule/core/2.2&#8221;:abstract-retry-policy, “http://www.mulesource.org/schema/mule/core/2.2&#8221;:service-overrides}’ is expected.
at org.mule.registry.AbstractRegistry.initialise(AbstractRegistry.java:76)
at org.mule.config.spring.SpringXmlConfigurationBuilder.createSpringRegistry(SpringXmlConfigurationBuilder.java:110)
at org.mule.config.spring.SpringXmlConfigurationBuilder.doConfigure(SpringXmlConfigurationBuilder.java:73)
at org.mule.config.builders.AbstractConfigurationBuilder.configure(AbstractConfigurationBuilder.java:39)
at org.mule.config.builders.AbstractResourceConfigurationBuilder.configure(AbstractResourceConfigurationBuilder.java:78)
at org.mule.context.DefaultMuleContextFactory.createMuleContext(DefaultMuleContextFactory.java:79)
at org.mule.tck.AbstractMuleTestCase.createMuleContext(AbstractMuleTestCase.java:474)
at org.mule.tck.AbstractMuleTestCase.setUp(AbstractMuleTestCase.java:443)
at junit.framework.TestCase.runBare(TestCase.java:132)
at org.mule.tck.AbstractMuleTestCase.runBare(AbstractMuleTestCase.java:295)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at org.mule.tck.AbstractMuleTestCase.run(AbstractMuleTestCase.java:274)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at ….. (much much more)
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.401 sec <<< FAILURE!

After some investigation it seemed I missed a dependency:

            <dependency>
                <groupId>com.mulesource.muleesb.modules</groupId>
                <artifactId>mule-module-spring-config-ee</artifactId>
                <version>2.2.7</version>
            </dependency>

The problem was that this was not documented (at least not in the places I looked ;-)). Luckily we solved it and is working fine now.

About Pascal Alma

Pascal is a senior IT consultant and has been working in IT since 1997. He is monitoring the latest development in new technologies (Mobile, Cloud, Big Data) closely and particularly interested in Java open source tool stacks, cloud related technologies like AWS and mobile development like building iOS apps with Swift. Specialties: Java/JEE/Spring Amazon AWS API/REST Big Data Continuous Delivery Swift/iOS
This entry was posted in Mule2 and tagged . Bookmark the permalink.