Question

i would like to define some sort of “retry policy” for a custom componenet i built, meaning retry on the initiailise function of the compoenent.

Is that supported by some XML tag (retry policy??) or would i have to implement the retries inside the initialise function itself? (which would mean i would have to handle the threads and stuff if i want to handle it like the “blocking” property of the EE edition)

And suppose there is some sort of retry attempts – what would happen if the component is still attempting to reinitialise while an inbound endpoint event is triggered? (or would that endpoint not register until the flow manages to start the component?)

In case i wasnt clear – this is the short example:

<flow>
    <quartz:inbound-endpoint jobName="eventTimer">
    <quartz:event-generator-job />
    </quartz:inbound-endpoint>

    <component>
        <singleton-object class="com.SomeComponent" />
    </component>

    <vm:outbound-endpoint path="ChatMsgs"
        exchange-pattern="one-way" />
</flow>

I’d like to set a “non-blocking” retry policy on the component and i would like the flow not to start until the component manages to initialise, is that asking too much of mule? 🙂

Thanks in advance

Answer 1

Non-blocking retry policies are now part of CE (since 3.2.0).

To have your component integrated with Mule’s lifecycle and retry policies, I suggest you develop it as a Mule module using DevKit (see “Mule’s Lifecycle Support” in http://blogs.mulesoft.org/introducing-the-new-devkit/). Though marketed as an “API connector toolkit”, DevKit does way way more things…

Of course, this would make your component Mule specific but with the benefit of making it a first-class citizen of Mule’s infrastructure.