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

Johan Almqvist updated CAMEL-25915:
-----------------------------------
    Component/s: camel-ftp
                 camel-mina-sftp

> camel-ftp - With sendNoop=false and a custom pollStrategy, an ftp consumer 
> does not reconnect after the server closed the connection
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25915
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25915
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-ftp, camel-mina-sftp
>            Reporter: Johan Almqvist
>            Priority: Minor
>
> h3. Problem
> Since CAMEL-25896, {{sendNoop=false}} also skips the noop that a consumer 
> sends before each poll. An ftp or ftps client does not notice a connection 
> that the server has closed, so such a consumer recovers in two ways:
> * A failure while retrieving or processing a file goes through 
> {{RemoteFileConsumer.handleException()}}, which makes the consumer send one 
> noop before the next poll.
> * A failure thrown out of {{poll()}} goes to the poll strategy, and 
> {{RemoteFilePollingConsumerPollStrategy.rollback()}} calls 
> {{forceDisconnect()}}.
> The second only works with the default poll strategy. With 
> {{pollStrategy=#myStrategy}}, for example a plain 
> {{DefaultPollingConsumerPollStrategy}} or a 
> {{LimitedPollingConsumerPollStrategy}}, nothing disconnects. The client still 
> regards itself as connected, so every following poll fails on its first 
> command ({{PWD}} with the default {{stepwise=true}}), and the consumer never 
> connects again. A {{LimitedPollingConsumerPollStrategy}} suspends the 
> consumer after 3 failed polls. Before CAMEL-25896 the noop before each poll 
> recovered whatever the poll strategy was.
> This was found in the review of https://github.com/apache/camel/pull/28195, 
> with a reproducer on the embedded FTP server: 
> {{ftp://...?delete=true&delay=100&sendNoop=false&pollStrategy=#myPollStrategy}},
>  consume a file, call {{disconnectAllSessions()}}, put a second file. The 
> result was 1 login, 96 failed polls and no message received. Without 
> {{sendNoop=false}}, the consumer logged in again and received the file.
> h3. Proposal
> Override {{poll(Exchange)}} in {{RemoteFileConsumer}} to call 
> {{sendNoopOnNextPollIfIOFailure(e)}} before it rethrows. With the default 
> poll strategy, {{forceDisconnect()}} clears the flag again, so nothing 
> changes there.
> h3. Documentation
> Also from that review: the mina-sftp noop is {{stat("/")}}, a request that 
> waits for the reply, unlike the JSch keep-alive. With {{sendNoop=false}}, a 
> mina-sftp connection that dropped silently is therefore found by the next 
> poll, which fails and is logged before the consumer connects again. The 4.24 
> upgrade guide and the {{setSendNoop()}} Javadoc should say so, and point to 
> {{serverAliveInterval}}, which makes either sftp client close such a 
> connection itself.
> A PR is ready; please assign this ticket to me.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to