Johan Almqvist created CAMEL-25915:
--------------------------------------
Summary: 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
Reporter: Johan Almqvist
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)
