Apache Camel 3.x SFTP文件上传重试异常：文件反复重传问题排查

针对你遇到的SFTP上传重试耗尽后，约1小时文件被重复触发的问题，核心原因大概率和组件的轮询机制、幂等性配置、错误处理策略有关，具体分析如下：

1. File端点（selection类型）的轮询与幂等性缺失 #

selection类型基于file端点同步处理，若未正确配置幂等性或失败文件处理逻辑，会导致以下情况：

• file组件默认会定期轮询源目录（若你配置过consumer.delay为3600000则是1小时，默认是5分钟），只要文件仍在源目录且未被标记为已处理，就会被重新触发上传。
• 若未开启idempotent=true或未配置有效的idempotentRepository（如基于文件系统的FileIdempotentRepository），即使之前已重试失败，file组件无法识别该文件已处理过，会重复发起上传。
• 另外，若未配置moveFailed参数指定失败文件的转移目录，失败文件会留在源目录，持续被轮询器扫描到。

2. SEDA端点（status/data类型）的消息持久化与死信队列缺失 #

status和data用SEDA异步处理，若存在以下配置问题会导致重复触发：

• 若使用了持久化SEDA（seda:endpoint?persistent=true），重试耗尽后未被正确处理的消息会被持久化到磁盘，当Camel重启或SEDA消费者重新初始化时，会重新读取这些消息并发起上传。
• 未配置死信队列（DLQ）：当重试次数耗尽后，若错误处理策略未将失败消息转移到DLQ（如通过deadLetterUri配置），消息可能被意外放回SEDA队列，或因SEDA的内部机制在一段时间后重新投递。

3. 错误处理策略的覆盖范围不匹配 #

抽象类SftpUploader统一配置路由，但错误处理规则可能未覆盖所有场景：

• 你配置的重试规则（如RedeliveryPolicy）可能仅作用于路由内的处理器，未覆盖file组件自身的消费者重试逻辑。file组件的consumer.maximumRetryAttempts和consumer.retryDelay是独立于全局错误处理的配置，若这两个参数未设置，组件会按默认逻辑重复轮询。
• 若onException或自定义ErrorHandler的作用范围仅针对SEDA路由，未覆盖file路由，会导致file路由的失败文件无法被正确标记或转移。

次要问题：重试日志级别为WARN #

Camel的RedeliveryErrorHandler默认以WARN级别输出重试日志，若要改为DEBUG，需调整日志框架（如log4j2、slf4j）的配置，将org.apache.camel.processor.RedeliveryErrorHandler的日志级别设为DEBUG。

建议排查方向 #

• 检查file端点配置：确认是否开启idempotent=true，配置idempotentRepository，并设置moveFailed到指定目录。
• 检查SEDA端点配置：若使用持久化SEDA，确认是否需要清理持久化存储；配置deadLetterUri将重试耗尽的消息转移到死信队列，避免重复消费。
• 统一错误处理策略：在抽象类中配置全局ErrorHandler，确保覆盖所有路由类型，明确重试耗尽后的处理逻辑（如标记失败、转移文件/消息）。
• 核对file组件的consumer.delay配置，确认是否为1小时，这可能是重复触发的时间间隔来源。

内容的提问来源于stack exchange，提问作者cdprete