Which mule transports does the re-connection strategy work with

Question

The reconnection strategies documentation only uses JMS examples, however the FTP transport documentation does state the use of re-connection strategies, without any details or examples though.

Further if you look at this answer @David mentions that re-connection will work with only some transports (connected transport).

So my first question -- Can we have some formal mechanism/guidelines/rules of determining which transports the re-connection mechanism will work with and for which it does not apply .. This can probably be deciphered, but a something concrete would be great ..

My second question is a simpler explanation of the below paragrapgh from the mule documentation :)

For an FTP transport configured with synchronous inbound and outbound endpoints, but no reconnection strategy, all inbound messages fail if the outbound connection goes down, because the inbound endpoint continues to receive messages. By contrast, with a reconnection strategy in place, the system loses the first message that fails (since FTP is not transactional) but once the reconnection strategy goes into effect, no further messages are accepted by the inbound endpoint (and thus, none are lost) until the connection is re-established.

When they say the below line, do they mean re connection at inbound or outbound ? and similarly are they assuming loss of connection at inbound or outbound

By contrast, with a reconnection strategy in place

My third question is from this lengthy discussion at various points in the discussion like the below

Reconnection has nothing to do with outbound retries, it doesn't come into play when attempts to send outbound fail but only for connected transports (like JMS) that needs to handle unexpected disconnections.

It seems like we are being told that reconnection strategy does not apply to outbound endpoints, can someone clarify if I have understood this correctly please.

Answer 1

Most of the lengthy discussion comes from the confusion between reconnection and retry: the former acts at connector/endpoint level and ensures that endpoints keep working (poller polls, listeners listen, dispatchers dispatch), the latter acts at message level and ensures that no message gets lost in an endpoint.

---

In the case of FTP, Mule does not maintain long running outbound connections, but it validates them with a noop (see: https://github.com/mulesoft/mule/blob/mule-3.x/transports/ftp/src/main/java/org/mule/transport/ftp/FtpMessageDispatcher.java#L109 for outbound endpoints and https://github.com/mulesoft/mule/blob/mule-3.x/transports/ftp/src/main/java/org/mule/transport/ftp/FtpMessageReceiver.java#L229 for inbound endpoints).

So, if a remote server issue is detected when uploading a file, and if a reconnection strategy is configured on the FTP connector, Mule will recycle the connector.

When Mule recycles a connector, it shuts down and restarts all its related endpoints (more technically: message receivers and dispatchers).

Because Mule validates FTP endpoints (see above), the connector will not reach the started state if any of its inbound or outbound endpoints can't perform the test FTP noop.

Based on this, the discussion about FTP in your question should become clearer. If the remote FTP server issue that initially made Mule recycle the FTP connector persists, none of the in/outbound endpoints managed by this connector will reach the started state, even if these endpoints deal with completely different FTP servers.