Java 为什么camel在inflightrepository中保留交换？

我的团队有一个通过ApacheCamel运行的工作（非常简单）服务，功能上一切都测试正常，但负载测试表明该服务随着时间的推移会消耗内存。从堆转储中挖掘出内存消耗来自机上存储库。似乎通过路由发送的每一个exchange都被保留，但我们无法确定在路由完成并成功交付exchange后保留exchange的任何原因

我的团队对这个问题的最初（下意识）反应是内存泄漏，但我不认为是这种情况——我们只是有一个意外的动作——交换从未被取消引用，所以垃圾收集不会试图处理它们

困难的部分在于，似乎要保留的不仅仅是exchange的一个副本，而是exchange生命周期的每一步都要保留，虽然路由并不特别复杂，但它确实实现了一个拆分聚合路由，从而夸大了问题

我们已经考虑添加一个组件来清除inflightrepository中过时的交换，但这并没有抓住要点

---

有人能解释骆驼为什么会这样做吗？

经过大量的挖掘，解决方案变得非常简单。路由生成自定义exchangeId，以简化对客户端请求的exchange跟踪。结果是，在路由结束时，当exchange被销毁（从机上存储库中删除）时，存储库中exchangeId:exchange的键：值映射不包含自定义exchangeId，并且由于明显的原因，不会删除已完成的exchange

这似乎是使用聚合策略的副作用。如果没有这一点，交易所将如预期的那样被取消

---

简而言之，这是用户错误…

没有代码？我在我的路由中没有看到这种行为。如果不提供服务的全部代码（本身就是一组相当大的代码），提供一些代码片段将是毫无意义的。但这不是问题所在——保留空中交流的原因是什么？也许“骆驼什么时候从inflightrepository中删除一个交换？”是一个更好的问题……我没有看到这种行为。根本没有用户错误。您的回答帮助我认识到了这个问题，但事实上，Camel有一个由exchangeId索引的机上存储库，我们可以简单地执行

exchange.setId（“mashedpatos”）

，而这不会自动更新所述存储库是框架的错，而不是我们的错。这种行为应该被封装起来。我们刚刚遇到了一个应用程序崩溃，因为这个问题导致了内存泄漏。