[
https://issues.apache.org/jira/browse/CAMEL-25915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-25915:
--------------------------------
Fix Version/s: 4.24.0
> 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
> Fix For: 4.24.0
>
>
> 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)
