Mule FTP опрос останавливается без ошибок или предупреждения

Question

У меня возникла проблема с FTP-опросом Mule ESB отдельно: Приложение работало в течение нескольких дней без проблем, а затем опрос FTP прекратился без предупреждения или ошибки.

Журналы показывали признаки активности для FTP-опроса, пока он не остановился. Впоследствии ничего, но другие разъемы все еще активны (в основном, опрос SFTP). Я включил протокол DEBUG во время выполнения, чтобы узнать, была ли еще активность, а соответствующие потоки соединителей были полностью бесшумными, как если бы они остановились или заблокированы.

В конце концов, перезапуск приложения разрешил проблему временно, но я пытаюсь понять, почему это произошло, чтобы избежать столкновения с ней снова. Мое подозрение в том, что потоки соединителей FTP либо остановлены, либо заблокированы, что предотвращает дальнейшие опросы.

Это может быть вызвано расширенным FtpMessageReceiver, которое мы использовали для предотвращения удаления файла после опроса (переопределение функции postProcess()). Однако, глядя в исходный код как этого компонента, так и базового FTP-приемника и соединителя, я не вижу, как это может произойти.

Любая идея, почему опрос внезапно прекратится без ошибки?

Вот текущая конфигурация разъема:

<ftp:connector name="nonDeletingFtpConnector" doc:name="FTP" 
     pollingFrequency="${frequency}" 
     validateConnections="true"> 
    <reconnect frequency="${frequency}" count="${count}"/> 
    <service-overrides messageReceiver="my.comp.NonDeletingFtpMessageReceiver" /> 
</ftp:connector> 

И соответствующая конечная точка:

<ftp:inbound-endpoint host="${ftp.source.host}" 
      port="${ftp.source.port}" 
      path="${ftp.source.path}" 
      user="${ftp.source.login}" 
      responseTimeout="10000" 
      password="${ftp.source.password}" 
      connector-ref="archivingFtpConnector" 
      pollingFrequency="${ftp.default.polling.frequency}"> 
     <file:filename-wildcard-filter pattern="*.zip"/> 
    </ftp:inbound-endpoint> 

Код MessageReceiver:

public class NonDeletingFtpMessageReceiver extends FtpMessageReceiver { 
    public NonDeletingFtpMessageReceiver(Connector connector, FlowConstruct flowConstruct, InboundEndpoint endpoint, long frequency) throws CreateException { 
     super(connector, flowConstruct, endpoint, frequency); 
    } 

    @Override 
    protected void postProcess(FTPClient client, FTPFile file, MuleMessage message) throws Exception { 
     //do nothing 
    } 
} 

Как вы можете видеть, что мы определили FtpMessageReceiver к избегайте удаления файла в опросе (это делается дальше по потоку), но, глядя в код, который я не вижу, может вызвать проблемы при пропуске вызова super.postProcess() (который отвечает за удаление файла).

FtpMessageReceiver исходный код, который я посмотрел: https://github.com/mulesoft/mule/blob/mule-3.5.0/transports/ftp/src/main/java/org/mule/transport/ftp/FtpMessageReceiver.java

Техническом конфига:

• Mule Standalone 3.5.0
• Ubuntu 14.04.2 LTS
• Java OpenJDK Runtime Environment (IcedTea 2,5. 6) (7u79-2.5.6-0ubuntu1.14.04.1)

Любая помощь будет оценена по достоинству. Спасибо заранее!

Answer 1

Как обсуждалось в комментариях, ошибка была больше связана с FTP-клиентом Apache, и я создал конкретное сообщение here.

Решение найдено: с помощью настраиваемого FtpConnectionFactory для правильного конфигурирования клиента с использованием значения таймаута> 0. Таким образом, зависание прерывается с выделением исключения таймаута.

public class SafeFtpConnectionFactory extends FtpConnectionFactory{ 

     //define a default timeout 
     public static int defaultTimeout = 60000; 
     public static synchronized int getDefaultTimeout() { 
      return defaultTimeout; 
     } 
     public static synchronized void setDefaultTimeout(int defaultTimeout) { 
      SafeFtpConnectionFactory.defaultTimeout = defaultTimeout; 
     } 

     public SafeFtpConnectionFactory(EndpointURI uri) { 
      super(uri); 
     } 

     @Override 
     protected FTPClient createFtpClient() { 
      FTPClient client = super.createFtpClient(); 

      //Define the default timeout here, which will be used by the socket by default, 
      //instead of the 0 timeout hanging indefinitely 
      client.setDefaultTimeout(getDefaultTimeout()); 

      return client; 
     } 
    } 

И затем присоединив его к разъему:

<ftp:connector name="archivingFtpConnector" doc:name="FTP" 
     pollingFrequency="${frequency}" 
     validateConnections="true" 
     connectionFactoryClass="my.comp.SafeFtpConnectionFactory"> 
    <reconnect frequency="${reconnection.frequency}" count="${reconnection.attempt}"/> 
</ftp:connector> 

Я попытаюсь обновить этот ответ, если есть какие-либо заметные изменения на другой.