Spring Integration实现SFTP远程文件复制的日志与阻塞问题咨询

一、多余LogAccessor日志消除方案 #

首先明确两类日志的实际来源：

• 告警日志Failed to delete [本地文件路径]：来自SFTP GET网关内置逻辑——配置FileExistsMode.REPLACE时，网关会尝试覆盖本地旧临时文件，删除失败时由内部操作链路通过LogAccessor输出告警。因为GET网关默认在覆盖本地文件时会触发自动删除，和你后续业务代码自己写的本地删除逻辑形成了重复操作，当文件被其他进程占用时，网关的删除逻辑就会抛出告警，而这个告警不属于业务流程需要感知的内容。
• 两条打印GenericMessage结构的INFO日志：来自流程链中你手动配置的两个.log()处理器，底层依托Spring LogAccessor实现日志输出，因此日志来源显示为该类。

对应的消除方式：

• 关闭网关自动删除本地文件的内置逻辑，避免无意义告警输出。在GET网关的配置中增加参数：

  .localFileDeleteMode(AbstractRemoteFileOutboundGateway.LocalFileDeleteMode.NO_DELETE)
  

  所有本地临时文件的清理完全由业务代码控制，从根源上避免网关的删除告警。
• 若不需要默认的消息结构打印，可直接移除流程链中的两个.log()配置；如需保留日志能力，可自定义输出内容，避免打印冗余的完整消息结构：

  // 替换原有.log()写法，自定义日志输出
  .log(LoggingHandler.Level.INFO, "SftpCopyService", 
       m -> "远程文件拉取完成，本地路径：" + m.getPayload())
  

• 若仍有网关内部无意义日志输出，可在日志配置文件中对对应包的日志级别做过滤：

  <logger name="org.springframework.integration.file.gateway" level="WARN" additivity="false"/>
  

二、无本地磁盘中转的SFTP复制实现（含阻塞问题修复） #

之前代码的核心阻塞原因 #

你之前尝试用readRaw实现复制时出现永久阻塞，核心原因是操作顺序不符合JSch通道的状态机要求：

• 原始读取模式（readRaw）下，SFTP通道会进入阻塞状态，等待读操作的所有应答包（ack）完全处理完成后，才会响应后续的写请求。你直接把readRaw返回的输入流传给session.write()方法，等于让同一个通道同时处理读、写两类操作，永远等不到读操作的应答循环退出，就卡死在你看到的_put方法的循环逻辑里。
• session.finalizeRaw()的调用时机错误，没有等读操作完全结束就发起写请求，进一步加剧了通道的状态混乱。

优化后的正确实现逻辑 #

该方案不写入本地磁盘文件，所有文件内容在应用内存中完成中转，比原有落本地临时文件的方案性能更高，也不会出现本地文件删除失败的问题：

public boolean copy() {
   return remoteFileTemplate.execute(session -> {
        String sourcePath = "uploads/Spring Integration.txt";
        String destPath = "uploads/dest/spring.txt";
        // 前置校验：源文件存在性检查
        if (!session.exists(sourcePath)){
            return false;
        }
        // 目标目录存在性检查
        String destParentDir = destPath.substring(0, destPath.lastIndexOf('/'));
        if (!session.exists(destParentDir)){
            session.mkdir(destParentDir);
        }
        try (InputStream sourceStream = session.readRaw(sourcePath)) {
            // 先完整读取源文件内容，结束整个读操作流程
            byte[] fileContent = sourceStream.readAllBytes();
            // 读流程完全结束后，再发起写操作
            try (OutputStream destStream = session.getRemoteSession().put(destPath, null)) {
                destStream.write(fileContent);
                destStream.flush();
            }
        } finally {
            // 所有原始流操作完成后，退出原始读取模式
            session.finalizeRaw();
        }
        return true;
    });
}

补充说明 #

• 因为SFTP协议本身没有原生的服务端同路径复制指令，上述方案属于应用侧的内存中转，比落本地磁盘的方案减少了两次本地磁盘IO，无临时文件清理问题。
• 如果单文件大小超过内存承受上限，可改为分块读取写入逻辑，但必须保证同一通道内，前一次读操作的所有数据完全传输完成后，再发起写操作，避免再次出现通道阻塞。
• 如果SFTP服务端支持原生的服务端复制扩展（OpenSSH 9.0及以上版本内置的copy扩展），可直接使用对应扩展接口实现服务端零拷贝复制，完全不需要应用侧参与流传输。

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