Spring integration Spring文件入站通道适配器速度减慢

我有一个spring集成流，它从一个由事务轮询器激活的文件入站通道适配器开始（tx由atomikos处理）。 文件中的文本将被处理，消息将通过流向下传递，直到它被发送到一个JMS队列（JMS出站通道适配器）。 在中间，在嵌套事务中有一些数据库写入。 该系统将全天候运行

碰巧单个消息流逐渐变慢，当我调查时，我发现导致延迟增加的阶段是从文件系统读取

下面是集成流程的第一部分：

<logging-channel-adapter id="logger" level="INFO"/>
<transaction-synchronization-factory id="sync-factory">
    <after-commit expression="payload.delete()" channel="after-commit"/>
</transaction-synchronization-factory>
<service-activator input-channel="after-commit" output-channel="nullChannel" ref="tx-after-commit-service"/>



<!-- typeb inbound from filesystem -->
<file:inbound-channel-adapter id="typeb-file-inbound-adapter"
                              auto-startup="${fs.typeb.enabled:true}"
                              channel="typeb-inbound"
                              directory="${fs.typeb.directory.in}"
                              filename-pattern="${fs.typeb.filter.filenamePattern:*}"
                              prevent-duplicates="${fs.typeb.preventDuplicates:false}" >
    <poller id="poller"
            fixed-delay="${fs.typeb.polling.millis:1000}"
            max-messages-per-poll="${fs.typeb.polling.numMessages:-1}">
        <transactional synchronization-factory="sync-factory"/>
    </poller>
</file:inbound-channel-adapter>
<channel id="typeb-inbound">
    <interceptors>
        <wire-tap channel="logger"/>
    </interceptors>
</channel>

我读了一些关于“防止重复”选项的相关问题，该选项存储一个已看到文件的列表，但事实并非如此，因为我已将其关闭。 我不认为这可能与过滤器（文件名模式）有关，因为我在配置（*.RCV）中使用的表达式很容易应用，并且输入文件夹不会同时包含很多文件（少于100个）

不过，随着时间的推移，从文件系统读取的速度会逐渐变慢，在几天的运行时间内，从几毫秒到超过3秒

---

有任何提示吗？

您应该删除或在处理完文件后移动它们；否则，必须重新扫描整个目录

在较新的版本中，您可以使用更高效的

---

但清理旧文件仍然是最佳做法。

我终于找到了解决方案。 这个问题与我使用的Spring的特定版本（4.3.4）有关，该版本受到我尚未发现的bug的影响。 问题在于DefaultConversionService和converterCache的使用（有关更多详细信息，请参阅本文）。

---

升级到较新版本的问题已经解决。

是的，我已经在执行删除操作（我已经考虑过了）。正如您所看到的，我有一个事务同步，但它不能解决这个问题<代码>我不愿意使用WatchServiceDirectoryScanner，因为我担心在将文件完全写入文件夹之前，文件可能会被拾取（更容易）。我知道，可以通过主要与编写器相关并由读者支持的方法来防止这种情况，但目前我们还没有这些方法中的任何一种。这是不是

payload.delete（）

奏效了？事务处理后文件真的被删除了吗？您能否确认已处理的文件已被删除，并且未保存在两者之间的某个位置？我的意思是，确保在使用完文件资源后关闭它。这是一个很好的观点。我确信文件会被删除，并且在应用程序的早期，这种情况会很快发生。我假设，

payload.delete（）

不需要对文件进行任何其他定稿，但我将更好地研究这个主题。

File.delete（）

可以返回

false

，如果无法删除文件，但没有任何异常。这就是为什么我建议您确保这确实符合应用程序的目的。