[
https://issues.apache.org/jira/browse/CAMEL-25916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Johan Almqvist updated CAMEL-25916:
-----------------------------------
Affects Version/s: 4.23.0
> 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
> Components: camel-ftp
> Affects Versions: 4.23.0
> Reporter: Johan Almqvist
> Priority: Major
>
> 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)
