Spring Integration重启后目录现有文件未被轮询/处理的问题排查

问题背景 #

使用Spring Integration XML配置文件入站通道适配器，配置了fixed-rate=1000的轮询器，同时启用AcceptFileOnlyOnce过滤器和多线程taskExecutor。目录路径为/apps/emailService/input，遇到以下问题：

• 重启应用后，目录中已有的10000个文件完全不被处理
• 有时目录已有文件时，新传入的文件也无法处理

疑问1：目录未加file:前缀是否是问题根源？改为file:/apps/emailService/input能否解决？ #

不是。Spring Integration文件入站适配器对绝对路径的解析兼容两种写法，无论是否带file:前缀，都能正确识别目标目录。修改路径格式无法解决当前问题。

疑问2：是否存在默认禁用、需要手动启用的属性来解决该问题？ #

有两个关键属性需要调整，直接影响文件处理逻辑：

• startup-delay：轮询器默认启动后立即开始轮询，但当目录存在大量文件（如10000个）时，初始化阶段过滤器全量扫描文件可能导致线程阻塞，后续轮询无法正常触发。建议给轮询器添加startup-delay="1000"，让应用完成启动后再开始轮询，避免初始化冲突。
• max-messages-per-poll：默认值为1，即每次轮询仅处理1个文件。面对10000个文件时，处理效率极低，且多线程场景下无法充分利用taskExecutor的线程资源，容易导致新文件积压。建议根据服务器性能调整该值，例如设置max-messages-per-poll="100"，让每次轮询批量获取文件交给线程池处理。

另外补充：AcceptFileOnlyOnce过滤器默认用内存存储已处理文件标记，重启后标记会丢失，理论上重启后应重新处理所有文件，但你遇到的“完全不处理”问题，大概率是轮询器未正常触发或初始化阶段卡住，优先调整上述两个属性排查。

疑问3：开启scan-each-poll=true是否会与AcceptFileOnlyOnce过滤器冲突？性能影响如何？ #

• 冲突问题：完全不会冲突。scan-each-poll控制的是每次轮询时是否全量扫描目录，而AcceptFileOnlyOnce过滤器负责判断文件是否已被处理，两者职责独立，不存在逻辑冲突。
• 性能影响：默认scan-each-poll=false时，适配器仅在启动时扫描一次目录，后续轮询仅检查目录修改时间，有变化才重新扫描；开启true后，每秒轮询（fixed-rate=1000）都会全量扫描10000个文件，会产生一定IO开销。如果服务器IO性能一般，可能导致轮询线程占用过高，甚至影响其他业务。
  如果你需要重启后重新扫描目录，或者目录文件动态变化频繁，开启该属性是必要的。可以搭配调整max-messages-per-poll降低单次处理压力，若IO压力过大，可适当降低轮询频率（如fixed-rate=5000），或改用基于文件系统事件的directory-watcher替代轮询器，性能会更优。
  额外建议：如果需要重启后避免重复处理文件，不要用默认的内存版AcceptFileOnlyOnce，换成PersistentAcceptFileListFilter，将已处理记录持久化到文件或数据库中。

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