<http:listener path="exhaustRedelivery" config-ref="listenerConfig">
<redelivery-policy maxRedeliveryCount="10" idExpression="#[payload.transaction.id]"/>
</http:listener>
Mule Sources
Standard Support for Mule 4.1 ended on November 2, 2020, and this version of Mule reached its End of Life on November 2, 2022, when Extended Support ended. Deployments of new applications to CloudHub that use this version of Mule are no longer allowed. Only in-place updates to applications are permitted. MuleSoft recommends that you upgrade to the latest version of Mule 4 that is in Standard Support so that your applications run with the latest fixes and security enhancements. |
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:
-
File Directory Listener (On New or Updated File)
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 .
|
Redelivery Policy Configuration Parameters
Field | Type | Default Value | Description |
---|---|---|---|
Max Redelivery Count |
Number |
5 |
The maximum number of times a message can be redelivered and processed unsuccessfully before raising a |
Use Secure Hash |
Boolean |
True |
Whether to use a secure hash algorithm to identify a redelivered message. |
Message Digest Algorithm |
String |
SHA-256 |
The secure hashing algorithm to use. Note: If the payload of the message is a Java object (for instance, when received by a |
ID Expression |
Expression |
- |
Defines one or more expressions to use to determine when a message has been redelivered. This property can only be set if |
Object Store |
String |
An Object Store created by the |
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
, anMULE:REDELIVERY_EXHAUSTED
error will be thrown. -
If the processing flow does not cause an exception, its counter gets reset.
Throws
-
MULE:REDELIVERY_EXHAUSTED
When the number of executions that raise an error is greater than the configured
maxRedeliveryCount
.
Examples
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"/>
</http:listener>
<flow-ref name="processData"/>
<error-handler>
<on-error-continue type="MULE:REDELIVERY_EXHAUSTED">
<logger message="Redelivery exhausted in http listener" level="ERROR"/>
</on-error-continue>
</error-handler>
</flow>