You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Johan Almqvist (Jira)" <ji...@apache.org> on 2026/10/21 09:25:00 UTC
[jira] [Created] (CAMEL-25916) camel-ftp - The NOOP before each rename or delete ignores sendNoop
Johan Almqvist created CAMEL-25916:
--------------------------------------
Summary: camel-ftp - The NOOP before each rename or delete ignores sendNoop
Key: CAMEL-25916
URL: https://issues.apache.org/jira/browse/CAMEL-25916
Project: Camel
Issue Type: Improvement
Reporter: Johan Almqvist
h3. Problem
{{FtpOperations.deleteFile()}} and {{renameFile()}} call {{reconnectIfNecessary()}}, which sends a {{NOOP}} whenever the client is connected, whatever {{sendNoop}} is set to. For ftp and ftps:
* The consumer sends one for each processed file unless {{noop=true}}, because it deletes the file ({{delete=true}}) or moves it (the default {{.camel}} move, {{move}}, {{moveFailed}}, {{preMove}}). {{readLock=rename}} and done files add more.
* The producer sends one when it renames a {{tempFileName}} to the target name, and when it deletes an existing file or a done file.
So {{sendNoop=false}} turns off the producer's pre-write check and, since CAMEL-25896, the consumer's pre-poll check, but not these. The 4.24 upgrade guide says so. {{SftpOperations}} and {{MinaSftpOperations}} only check {{isConnected()}} before a rename or delete.
h3. Proposal
Let {{reconnectIfNecessary()}} follow {{sendNoop}}: with {{sendNoop=false}} it only checks {{isConnected()}}, as the pre-poll and pre-write checks do. The default stays {{true}}, so nothing changes unless the option is set.
h3. Trade-off to decide first
This NOOP protects a rename or delete after a long-running route. If the server closed the idle connection while the route ran, the client connects again before it moves or deletes the file. Without the NOOP, that rename or delete fails, the file stays where it is, and the next poll processes it again unless an idempotent repository prevents that. Anyone who sets {{sendNoop=false}} would accept that risk, and the option description and upgrade guide would have to say so. If that is too much, the alternative is to keep the code as it is, as the upgrade guide already documents the NOOP.
Raised by [~davsclaus] in the review of https://github.com/apache/camel/pull/28195.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)