Question

我们有一个使用以下

的Spring Integration项目

 <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>

我们还有一个从默认的RecursiveLeafOnlyDirectoryScanner扩展的leafScanner，我们的leafscanner不会做太多。只需根据正则表达式属性检查目录。

我们看到的问题是有250,000个（.landed [我们关心的]文件），这意味着我们正在轮询的目录中有大约500,000个实际文件。这是旧系统的重新设计，重新设计是为了使应用程序更具可伸缩性，同时不知道轮询父目录中的目录名称。我们希望远离每个特定目录的轮询器，但似乎除非我们做错了什么，否则我们将不得不回到此处。

如果有人有任何可能的解决方案或配置项我们可以尝试，请告诉我。在我的本地机器上有66k。的文件，大约需要16分钟才能将第一个文件提交给我们的变压器做一些事情。

Answer 1

正如JavaDocs指出的那样，RecursiveLeafOnlyDirectoryScanner不能很好地扩展到大型目录或深树。

您可以使leafScanner有状态，而不是子类化RecursiveLeafOnlyDirectoryScanner，子类DefaultDirectoryScanner并实现listEligibleFiles，并在保存到您所在位置后有1000个文件时返回;在接下来的民意调查中，从你离开的地方继续;当你走到尽头时，从头开始。

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

Answer 2

只是一个更新。我们的实现速度太慢的原因是因为锁定（试图防止重复），通过添加过滤器自动禁用锁定（防止重复）。如果要添加线程池，则每次轮询的max-messages也非常重要。如果没有这个，你将看不到性能改进。

Spring Integration Poller太慢了

2 个答案: