java - Camel : File consumer component "bites off more than it can chew", 管道因内存不足错误而终止

Question

我在 Camel 中定义了一条路由，其内容如下:收到 GET 请求，在文件系统中创建一个文件。文件使用者接收它，从外部 Web 服务获取数据，并通过 POST 将结果消息发送到其他 Web 服务。

下面的简化代码:

    // Update request goes on queue:
    from("restlet:http://localhost:9191/update?restletMethod=post")
    .routeId("Update via POST")
    [...some magic that defines a directory and file name based on request headers...]
    .to("file://cameldest/queue?allowNullBody=true&fileExist=Ignore")

    // Update gets processed
    from("file://cameldest/queue?delay=500&recursive=true&maxDepth=2&sortBy=file:parent;file:modified&preMove=inprogress&delete=true")
    .routeId("Update main route")
    .streamCaching() //otherwise stuff can't be sent to multiple endpoints
    [...enrich message from some web service using http4 component...]
    .multicast()
        .stopOnException()
        .to("direct:sendUpdate", "direct:dependencyCheck", "direct:saveXML")
    .end();

多播中的三个端点只是将结果消息发布到其他 Web 服务。

当队列(即文件目录 cameldest )相当空时，这一切都工作得相当好。正在 cameldest/<subdir> 中创建文件，由文件消费者拾取并移至 cameldest/<subdir>/inprogress ，并且内容正在发送到三个传出 POST，没有问题。

但是，一旦传入请求堆积到大约 300,000 个文件，进度就会减慢，最终管道会因内存不足错误而失败(超出 GC 开销限制)。

通过增加日志记录，我可以看到文件使用者轮询基本上从不运行，因为它似乎对每次看到的所有文件负责，等待它们完成处理，并且只然后开始另一轮投票。除了(我认为)造成资源瓶颈之外，这也会干扰我的排序要求:一旦队列中挤满了数千条等待处理的消息，原本会被天真地排序到更高位置的新消息 - 如果它们仍然被拾取的话- 仍然在那些已经“开始”的后面等待。

现在，我已经尝试了 maxMessagesPerPoll和eagerMaxMessagesPerPoll选项。他们一开始似乎缓解了这个问题，但经过几轮投票后，我仍然有数千个文件处于“开始”状态。

唯一有效的方法是制作 delay 的瓶颈和maxMessages...如此之窄以至于处理的平均完成速度比文件轮询周期更快。

显然，这不是我想要的。我希望我的管道能够尽可能快地处理文件，但不能更快。我希望文件使用者在路线繁忙时等待。

我犯了一个明显的错误吗？

(我在带有 XFS 的 Redhat 7 机器上运行稍旧的 Camel 2.14.0，如果这是问题的一部分。)

Answer 1

尝试在 from file 端点上将 maxMessagesPerPoll 设置为较低的值，以便每次轮询最多仅拾取 X 个文件，这也会限制您在 Camel 应用程序中拥有的传输消息总数。

您可以在文件组件的 Camel 文档中找到有关该选项的更多信息