Until Successful, reconnection and redelivery policies
Tell Mule's three retry mechanisms apart by the failure each one handles: reconnection strategies for connections that cannot be established, Until Successful for processors that fail inside one event, and redelivery policies (or an Anypoint MQ dead-letter queue) for messages that keep failing, including how each behaves inside a transaction.
Recognize the purpose and characteristics of Until Successful scope, reconnection strategies, and redelivery policies.
~7 min read · 7 practice questions
What the exam expects
- Match a failure to its mechanism: a connection that cannot be established, a processor that fails inside an event, or a message that fails on every delivery.
- Predict reconnection behavior from the configured strategy and its defaults, including what happens at deployment.
- Recognize how Until Successful retries, how long it waits, what it raises, and what it does to threads inside a transaction.
- Configure a redelivery policy and handle
MULE:REDELIVERY_EXHAUSTEDso a poison message leaves the source, and recognize the Anypoint MQ queue-level alternative.
Reconnection strategy: how an operation or source re-establishes a connection after failing to connect. Until Successful: a scope that retries the processors inside it until they all succeed or retries run out. Redelivery policy: a filter on a flow's source that limits how many times Mule processes a message that keeps raising errors. Poison message: a message that fails on every attempt. Dead-letter queue (DLQ): a queue that receives messages that could not be delivered (Reconnection Strategies, Until Successful Scope, Configure a Redelivery Policy, Configuring and Using Queues).
Key facts
- Detail
- Default None: immediate connectivity error.
reconnect defaults- Detail
count2,frequency2000 ms.
reconnect-forever- Detail
- Retries at
frequency(default 2000 ms) while the app runs.
failsDeployment- Detail
- Default
false;truefails deployment when the test connection fails.
- Detail
- All processors in the scope, synchronously.
millisBetweenRetries- Detail
- Minimum gap, default 60000 ms, at most about twice the value.
- Detail
- Blocks the thread between retries.
- Detail
- Default 5; error when failures exceed it.
- Detail
- Nonpersistent default,
entryTtl300 s.
- Detail
- Transaction stays active and can commit.
- Detail
- Default 10, range 1-1000.
- Detail
- Two minutes when not set.
Sources for this section (6)
- Reconnection Strategiesdocs.mulesoft.com (opens in a new tab)
- Until Successful Scopedocs.mulesoft.com (opens in a new tab)
- Transaction Managementdocs.mulesoft.com (opens in a new tab)
- Configure a Redelivery Policydocs.mulesoft.com (opens in a new tab)
- Configuring and Using Queuesdocs.mulesoft.com (opens in a new tab)
- Anypoint MQ ACK and NACK Operationsdocs.mulesoft.com (opens in a new tab)
- Why can the real gap between Until Successful attempts be longer than
millisBetweenRetries? - When would you set
blocking="false"on a reconnection strategy? - What error does a Database Connector operation raise when it cannot connect and no strategy is configured?
- When does Mule evaluate a source's redelivery policy relative to the rest of the flow?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the MuleSoft Platform Integration Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 40 lessons of the MuleSoft Platform Integration Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Practice exams purchase adds inline bank questions and topic practice (7 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Choose guide-only, practice-only, or save $4 with both