Contact Free trial Login

Mule Sources

Sources are a very important part of any Mule app. When added to a flow, they serve as the entry point for information, linking any external communication protocol with internal Mule processing.

Examples of sources are:

Configuring Sources

Even though each source implementation will have different configuration parameters, some common ones are worth mentioning.

Redelivery Policy

A redelivery policy is a filter that is added to Mule Sources to prevent the dispatch of messages that are known to cause errors.

By adding a redelivery policy to a flow’s source, the received data will be evaluated prior to executing the flow’s components. If that data caused failures multiple times in the past, the redelivery policy will prevent the flow from processing it and a REDELIVERY_EXHAUSTED error will be raised instead.

This behavior prevents the runtime from wasting resources by executing a flow with poisoned messages (messages that caused errors in previous executions).

Some connectors have their own logic for handling an error thrown by a redelivery policy. In such cases, check the documentation for the connector to which that source belongs. For example, the http-connector might return 429: TOO MANY REQUESTS.
<http:listener path="exhaustRedelivery" config-ref="listenerConfig">
    <redelivery-policy maxRedeliveryCount="10" idExpression="#[]"/>

Redelivery Policy Configuration Parameters

Field Type Default Value Description

Max Redelivery Count



The maximum number of times a message can be redelivered and processed unsuccessfully before raising a MULE:REDELIVERY_EXHAUSTED error.

Use Secure Hash



Whether to use a secure hash algorithm to identify a redelivered message.

Message Digest Algorithm



The secure hashing algorithm to use.

Note: If the payload of the message is a Java object (for instance, when received by a vm listener), this option will be ignored and the value returned by the payload’s hashCode() method will be used.

ID Expression



Defines one or more expressions to use to determine when a message has been redelivered. This property can only be set if useSecureHash is false.

Object Store


An Object Store created by the ObjectStoreManager. Non-persistent, with an entryTtl of 300 SECONDS and an expiration interval of 6 SECONDS.

The Object Store where the redelivery counter for each message is to be stored. It can be configured as a reference or as an inner element. See Object Store connector

Redelivery Policy Functionality

The configured redelivery policy works as follows:

Each time a new message is received by the source, it gets digested. A key will be generated from the message, either by using the configured Message Digest Algorithm or by evaluating the ID Expression.

  • If the processing flow causes an exception, a counter associated with it gets incremented. Once the counter reaches a value bigger than the configured maxRedeliveryCount, an MULE:REDELIVERY_EXHAUSTED error will be thrown.

  • If the processing flow does not cause an exception, its counter gets reset.



    When the number of executions that raise an error is greater than the configured maxRedeliveryCount.


Suppose that you want to log some information when a maxRedeliveryCount is reached:

<flow name="logOnRedeliveryExhausted">
    <http:listener path="test" config-ref="listenerConfig">
        <redelivery-policy maxRedeliveryCount="2" useSecureHash="true"/>
    <flow-ref name="processData"/>
        <on-error-continue type="MULE:REDELIVERY_EXHAUSTED">
            <logger message="Redelivery exhausted in http listener" level="ERROR"/>

We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.