Contact Us 1-800-596-4880

Reconnection Strategies

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.

When an operation in a Mule application fails to connect to an external server, the default behavior is for the operation to fail immediately and return a connectivity error.

For example, if an operation in Anypoint Connector for FTP (FTP Connector) fails to connect to an FTP server, the operation throws an FTP:CONNECTIVITY error. The error name reflects the namespace that is specific to the connector, such as FTP:CONNECTIVITY, HTTP:CONNECTIVITY, or DB:CONNECTIVITY (for Anypoint Connector for Database (Database Connector).

You can modify this default behavior by configuring a reconnection strategy for the operation.

Configure an Operation Reconnection Strategy

You can configure a reconnection strategy for an operation either by modifying the operation properties or by modifying the configuration of the global element for the operation. For example, you can configure a reconnection strategy in an HTTP Request configuration:

Configure a reconnection strategy

The following are the available reconnection strategies and their behaviors:

  • None

    Is the default behavior, which immediately returns a connectivity error if the attempt to connect is unsuccessful

  • Standard (reconnect)

    Sets the number of reconnection attempts and the interval at which to execute them before returning a connectivity error

  • Forever (reconnect-forever)

    Attempts to reconnect continually at a given interval

Example XML Reconnection Strategy Configurations

The following examples show different types of reconnection strategies and their configurations:

  • Standard reconnection strategy example

    The following example illustrates a Standard reconnection strategy in an FTP connector configuration, setting the count of reconnection attempts before failing to 5 and setting failsDeployment to true, which causes the application deployment to fail if the connection test fails. Because a frequency is not specified, the retry interval is the default of every 2000 ms:

    <ftp:config name="FTP_Config" doc:name="FTP Config" >
      <ftp:connection host="ftp.someftphost.com" port="21" username="myusername" password="mypassword" >
        <reconnection failsDeployment="true" >
          <reconnect count="5"/>
        </reconnection>
      </ftp:connection>
    </ftp:config>
    <flow name="reconnectionsFlow" >
      <ftp:listener doc:name="On New or Updated File" config-ref="FTP_Config">
        <scheduling-strategy >
          <fixed-frequency />
        </scheduling-strategy>
      </ftp:listener>
    </flow>
  • Forever reconnection strategy example

    The following example sets a Forever reconnection strategy in an FTP connector configuration by which the connector attempts to reconnect every 4000 ms for as long as the application runs:

    <ftp:connection host="ftp.someftphost.com" port="21" username="myusername" password="mypassword" >
      <reconnection>
        <reconnect-forever frequency="4000"/>
      </reconnection>
    </ftp:connection>

Reconnection Strategy Reference

Following are the different configuration attributes for each reconnection strategy you can configure by editing your Mule application’s XML configuration file:

  • Attributes of <reconnection>

    Name Type Required Default Description

    failsDeployment

    boolean

    no

    false

    If true, causes the deployment to fail when the test connection fails

  • Attributes of <reconnect>

    Name Type Required Default Description

    blocking

    boolean

    no

    true

    If false, the reconnection strategy runs in a separate, nonblocking thread

    frequency

    long

    no

    2000

    How often (in ms) to reconnect

    count

    integer

    no

    2

    How many reconnection attempts to make

  • Child Elements of <reconnect>

    Name Cardinality Description

    abstract-reconnect-notifier

    0..1

    A placeholder for a reconnection notifier element
    The RetryNotifier interface is a callback that allows actions to be performed after each reconnection attempt, for example, firing server notification events on success or failure.

  • Attributes of <reconnect-forever>

    Name Type Required Default Description

    blocking

    boolean

    no

    true

    If false, the reconnection strategy runs in a separate, nonblocking thread.

    frequency

    long

    no

    2000

    Specifies how often (in ms) to reconnect.