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)