Question

I am attempting to set up a retry policy like so:

<spring:beans>
        <spring:bean id="threadingPolicyTemplate"
            class="org.mule.retry.async.AsynchronousRetryTemplate">
            <spring:constructor-arg index="0">
                <spring:bean id="foreverRetryPolicyTemplate"
                    class="com.Component.ChatConnectionRetryPolicyTemplate">
                    <spring:property name="sleepTime" value="${connector.retryInterval}" />
                </spring:bean>
            </spring:constructor-arg>
        </spring:bean>
    </spring:beans>

    <jdbc:connector name="jdbcConnector" dataSource-ref="SQLServerjdbcDataSource">
        <spring:property name="retryPolicyTemplate" ref="threadingPolicyTemplate"/>
        <jdbc:query key="PollDB"
            value="select * from ofMessageArchive where ID >  #[payload:]" />
    </jdbc:connector>

I use said connector as an outbound endpoint in my flow but I don’t see the retry policy even being called. (I’ve set breakpoints and so and they were not called).

I am using some sort of threaded SimpleRetryPolicy (nothing fancy).

One more question regarding the matter – suppose the connector doesn’t start up (retry policy is being attempted) – What would happen to a flow which uses the connector as an endpoint??

How does mule treat these things?

Answer 1

• Even if the JdbcConnector has noops for init/start/stop/dispose methods, your retry policy template is supposed to be called right after AbstractConnector.connect() logs “Connecting: “. Maybe you want to breakpoint at this place and follow through?

• If you use a threaded retry policy, Mule will start even if a connector is failed. Inbound endpoints depending on this connector will not start hence flows using them won’t get triggered until the connector can start. Outbound endpoints will throw exceptions: it’s up to you to deal with this situation, either with until-successful or an exception-strategy that perform some custom handling of the issue.