You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (JIRA)" <ji...@apache.org> on 2018/10/03 07:26:00 UTC

[jira] [Resolved] (CAMEL-12850) camel-ftp tries reconnects twice as much as maximumReconnectAttempts

     [ https://issues.apache.org/jira/browse/CAMEL-12850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-12850.
---------------------------------
    Resolution: Fixed

Thanks for the PR and looking into this

> camel-ftp tries reconnects twice as much as maximumReconnectAttempts
> --------------------------------------------------------------------
>
>                 Key: CAMEL-12850
>                 URL: https://issues.apache.org/jira/browse/CAMEL-12850
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-ftp
>    Affects Versions: 2.22.1
>            Reporter: Tadayoshi Sato
>            Assignee: Tadayoshi Sato
>            Priority: Major
>             Fix For: 2.21.3, 2.22.2, 2.23.0
>
>         Attachments: FtpTimeoutWithMaximumReconnectAttemptsTest.java
>
>
> When {{maximumReconnectAttempts > 0}} on the endpoint, both camel-ftp consumers and producers retry connecting to an unavailable FTP server twice as much as the number of {{maximumReconnectAttempts}}. It is because of the following logic in {{RemoteFileConsumer.prePollCheck()}} and {{RemoteFileProducer.preWriteCheck()}}:
> {code:java}
>                 if (getEndpoint().getMaximumReconnectAttempts() > 0) {
>                     // only use recoverable if we are allowed any re-connect attempts
>                     recoverableConnectIfNecessary();
>                 } else {
>                     connectIfNecessary();
>                 }
> {code}
> where {{recoverableConnectIfNecessary()}} retries {{RemoteFileOperations.connect()}} once in case of initial connection failure.
> Digging into the commit history, this logic appears to be introduced due to CAMEL-2829 as a workaround. However, since the root cause NET-327 is already resolved the logic doesn't seem to be necessary any more. So probably we can remove the logic to avoid attempting reconnects twice as much as {{maximumReconnectAttempts}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)