Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (4.1)
  3. Mule 4 for Mule 3 Users
  4. Migration to Mule 4
  5. Migrating Core Components

  6. Migrate Reconnection Strategies

Migrating 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.

From a syntax point of view, reconnection hasn’t changed much between Mule 3 and Mule 4. However, there are significant behavior differences.

In Mule 3, reconnection strategies were specified on each connector’s config element. These strategies had two purposes:

  • To reconnect when a running application looses connection to an endpoint

  • To validate all connections when the application is being deployed.

So, suppose an application which connects to a mysql Database. If that connection cannot be established at deployment time, the deployment will fail. This was to guarantee that all deployed apps are in a functioning state.

Mule 3 Examples: Reconnection Settings (for a MySQL database)
<db:mysql-config ...>
  <reconnect frequency="4000" count="4"/>`
</db:mysql-config>

<db:mysql-config ...>
  <reconnect-forever frequency="4000"/>`
</db:mysql-config>

However, there are use cases in which you don’t necessarily want the deployment to fail if connectivity fails. For example, your application might have a flow that reaches an external SFTP server only once a day at 3:00 AM. If the app is being deployed at 8:00 AM, there’s no reason for the deployment to fail if the SFTP server is down. You still have all day to make sure the server is up when it’s actually needed.

To achieve this with Mule 3, you had to use the blocking="false" option, so that reconnection happens asynchronously and deployment is not aborted.

Mule 3 Examples: Asynchronous reconnection Settings (for a MySQL database)
<db:mysql-config ...>
  <reconnect frequency="4000" count="4" blocking="false"/>`
</db:mysql-config>

In Mule 4 you can simply specify if deployment should fail or not if connectivity testing fails:

Mule 4 Examples: Reconnection Settings (for a SQL database)
<!-- fail deployment is connection cannot be established -->
<db:mssql-connection ...>
  <reconnection failsDeployment="true">
    <reconnect frequency="4000" count="4"/>
  </reconnection>
</db:mssql-connection>

<!-- don't fail deployment is connection cannot be established -->
<db:mssql-connection ...>
  <reconnection >
    <reconnect-forever frequency="4000" />
  </reconnection>
</db:mssql-connection>

By default, a failure to establish connection will only generate a warning in the logs.

Operation level reconnection strategy

In Mule 3, the same reconnection strategy at the config element was used both at deployment time and at runtime. For example, if connectivity to the Database is lost which executing a flow, the same reconnection strategy will be used.

In Mule 4 this behavior is kept by default, but you also get the chance to specify a different strategy at the operation or Message Source level:

Mule 4 Examples: Reconnection Settings (for an HTTP request)
<flow name="reconnectionDemo">
  <http:listener path="test" config-ref="httpListener">
    <reconnect count="1" frequency="5000"/>
    <http:response>
      <http:body>#[{'my': 'map'}]</http:body>
      <http:headers>
          #[{{'content-type' : 'text/plain'}}]
      </http:headers>
    </http:response>
  </http:listener>

  <http:request path="unreliable/endpoint" config-ref="httpRequester" method="GET">
    <reconnect count="1" frequency="1000"/>
  </http:request>

</flow>

See Also