Until Successful Scope in Mule
Learn how to use the Until Successful scope in Mule flows; learn its features and how it works in a code example.
Join the DZone community and get the full member experience.
Join For FreeThe until successful scope is one of the scopes available in Mule which processes messages through its processors until the process succeeds. By default, until successful’s processing occurs asynchronously from the main flow. After passing a message into the until successful scope, the main flow immediately regains control of the thread. However, you can configure until successful to run synchronously relative to the main flow.
The until successful component requires a mandatory object store to work. However, Anypoint Studio doesn’t enforce this. If an object store is not declared, Anypoint Studio throws an InitializationException. The object store needs to be exclusive for each Until Successful instance.
Below is the exception which will be thrown if object store is not declared for UntilSuccessful:
org.mule.module.launcher.DeploymentInitException: InitialisationException: A ListableObjectStore must be configured on UntilSuccessful.
By default, the Until Successful scope runs asynchronously, but you can always configure it as synchronous. For example, if the parent flow is calling a child flow in the Until Successful scope, the main flow will not halt for child flow to complete, it will immediately regains control of thread.
IMP Attributes of Until Successful Scope
objectStore-ref: Reference to the org.mule.api.store.ListableObjectStore that is used to store events pending to process or reprocess.
maxRetries: Specifies the maximum number of retries that are attempted.
millisBetweenRetries: Specifies the minimum interval between two attempts to process, in milliseconds. The actual interval depends on the previous execution, but should not exceed twice this number. The default value is 60000 milliseconds (one minute).
deadLetterQueue-ref: The endpoint or message processor to which undeliverables messages are sent after all retries have been executed unsuccessfully.
Syntax:
<until-successful objectStore-ref="objectStore"
failureExpression="#[message.inboundProperties['http.status'] != 202]"
maxRetries="6" secondsBetweenRetries="600">
<http:request config-ref="HTTP_Request_Configuration" path="flakey" method="POST" doc:name="HTTP"/>
</until-successful>
When All Else Has Failed
If message processing keeps failing and the maximum number of retries is exceeded, the default behavior of the until successful message processor consists of logging the message details and dropping it.
If we want to perform a specific action on the discarded message (for example, storing it in a file or database), it is possible to configure a "Dead Letter Queue endpoint” where dropped messages are sent.
Until-Successful and Object Store
This message processor needs a ListableObjectStore instance in order to persist messages pending (re)processing. There are several implementations available in Mule, including the following:
DefaultInMemoryObjectStore: default in-memory store.
DefaultPersistentObjectStore: default persistent store.
FileObjectStore: file-based store.
QueuePersistenceObjectStore: global queue store.
SimpleMemoryObjectStore: in-memory store.
Synchronous Until Successful
Out of the box, the until successful scope processes messages asynchronously. After passing a message into the until successful scope, the main flow immediately regains control of the thread, thus prohibiting any returned response from the processing activities which occur within the scope.
However, in some situations, you may need until successful to process messages synchronously so that the main flow waits for processing within the scope to complete before continuing processing. To address these needs, Mule enables you to configure the scope to process messages synchronously.
When set to process message synchronously, until successful executes within the thread of the main flow, then returns the result scope’s processing on the same thread.
When set to process synchronously, the until-successful scope does not accept the configuration of the following child element and attributes:
threading-profile (synchronous until-successful does not need a ThreadPool)
objectStore-ref (synchronous until-successful is not required to persist messages between retries)
deadLetterQueue-ref (when the retry count is exhausted, Mule executes the exception strategy)
Use Cases
The until successful message processor acts very much like a store-and-forward station: it stores any MuleEvent it receives and tries to process it a configured number of times at the defined retry frequency.
Let’s walk through how to use the until successful scope in a Mule application.
In this example, we have two flows. The first flow is "until-sucessfulFlow" with an HTTP Request connector which is making a request on localhost and port 8083 wrapped in the until successful scope. The second flow is "until-sucessfulRequestFlow," which is listening on localhost and port 8083. After making a request "http://localhost:8081/until/until" through the REST client, flow "until-sucessfulFlow" will be invoked and start calling the flow "until-sucessfulRequestFlow" until its able to deliver the message successfully. To replicate the failure case we can comment out our second flow "until-sucessfulRequestFlow" which will lead to the exception.
In case of failure, we will get the below exception:
Root Exception stack trace:
org.mule.retry.RetryPolicyExhaustedException: until-successful retries exhausted. Last exception message was: Response code 404 mapped as failure.
Flow:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:objectstore="http://www.mulesoft.org/schema/mule/objectstore" xmlns:db="http://www.mulesoft.org/schema/mule/db" xmlns:http="http://www.mulesoft.org/schema/mule/http"
xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xmlns:spring="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.mulesoft.org/schema/mule/db http://www.mulesoft.org/schema/mule/db/current/mule-db.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/objectstore http://www.mulesoft.org/schema/mule/objectstore/current/mule-objectstore.xsd">
<http:listener-config name="HTTP_Listener_Configuration"
host="0.0.0.0" port="8081" basePath="/until" doc:name="HTTP Listener Configuration" />
<http:request-config name="HTTP_Request_Configuration"
host="localhost" port="8083" basePath="/restcall" doc:name="HTTP Request Configuration" />
<http:listener-config name="HTTP_Listener_Configuration1"
host="localhost" port="8083" basePath="/restcall" doc:name="HTTP Listener Configuration" />
<spring:beans>
<spring:bean id="myListableObjectStore"
class="org.mule.util.store.SimpleMemoryObjectStore" />
</spring:beans>
<objectstore:config name="ObjectStore__Configuration" objectStore-ref="_defaultUserObjectStore" doc:name="ObjectStore: Configuration"/>
<flow name="until-sucessfulFlow">
<http:listener config-ref="HTTP_Listener_Configuration"
path="/until" doc:name="HTTP" />
<until-successful maxRetries="5" objectStore-ref="myListableObjectStore"
millisBetweenRetries="3000" doc:name="Until Successful">
<http:request config-ref="HTTP_Request_Configuration"
path="/restcall" method="POST" doc:name="HTTP" />
</until-successful>
<set-payload value="Request Processed successfully2"
doc:name="Set Payload" />
</flow>
<flow name="until-sucessfulRequestFlow">
<http:listener config-ref="HTTP_Listener_Configuration1"
path="/restcall" allowedMethods="POST" doc:name="HTTP" />
<set-payload value="Request Processed successfully1"
doc:name="Set Payload" />
</flow>
</mule>
Success Case:
Hope this helps.
Thanks.
Keep learning.
Opinions expressed by DZone contributors are their own.
Comments