Performance Spring集成轮询器太慢

我们有一个Spring集成项目，它使用以下

 <int-file:inbound-channel-adapter
        directory="file:#{'${poller.landingzonepath}'.toLowerCase()}" channel="createMessageChannel"
        filename-regex="${ingestion.filenameRegex}" queue-size="10000"
        id="directoryPoller" scanner="leafScanner">
<!--        <int:poller fixed-rate="${ingestion.filepoller.interval:10000}" max-messages-per-poll="100" /> -->
        <int:poller fixed-rate="10000" max-messages-per-poll="1000" />
    </int-file:inbound-channel-adapter>

我们还有一个leafScanner，它是从默认的RecursiveLeafOnlyDirectoryScanner扩展而来的，我们的leafScanner做的不多。只需根据regex属性检查目录

我们看到的问题是有250000个（.landed[我们关心的那些]文件），这意味着我们正在轮询的目录中有大约500k个实际文件。这是对旧系统的重新设计，重新设计的目的是使应用程序更具可伸缩性，同时不知道轮询父目录中的目录名。我们想避开每个特定目录的民意调查，但似乎除非我们做错了什么，否则我们必须回到这个问题上

---

如果任何人有任何可能的解决方案，或配置项目，我们可以尝试，请让我知道。在我的本地机器上，有66k.landed文件，第一个文件提交给我们的transformer需要大约16分钟的时间。正如JavaDocs所指出的，

RecursiveLeafOnlyDirectoryScanner

无法很好地扩展大目录或深树

您可以使您的

leafScanner

有状态，而不是子类化

RecursiveLeafOnlyDirectoryScanner

，子类化

DefaultDirectoryScanner

，实现

listeligablefiles

，并在保存完1000个文件后返回；在下一次投票中，从你停止的地方继续；当你到达终点时，从头开始

---

您可以在字段中维护状态（这意味着您将在JVM重新启动后重新启动），或者使用一些持久性。

只是一个更新。我们的实现如此缓慢的原因是由于锁定（试图防止重复），通过添加过滤器自动禁用锁定（防止重复）。

---

如果要添加线程池，则每次轮询的最大消息数也非常重要。如果没有这一点，您将看不到任何性能改进。

是的，我读过关于RecursiveLeafOnlyDirectoryScanner的文章，但我找不到提到的任何上限。