我的团队有一个工作（非常简单）的服务，通过apache camel运行，功能上所有测试都可以，但负载测试表明服务会随着时间消耗内存。深入研究堆转储，结果是内存消耗来自inflight-repository。似乎保留了通过该路线发送的每一个交易所，但我们无法确定在路线完成并且交易成功交付后应该保留交易所的任何理由。
对我的团队问题的最初（下意识）反应是，这是一个记忆泄漏，但我不相信这是事实 - 我们只是有一个意想不到的行动 - 交流永远不会-referenced所以垃圾收集不会尝试处理它们。
困难的是，它不仅仅是交换的一个副本，似乎是保留的，它是保留的交换生命周期的每一步，而路线并不特别复杂，它确实实现了分裂聚合路线，然后夸大问题。
我们考虑过添加一个组件来清除来自inflightrepository的陈旧交换，但这样做却错过了这一点。
任何人都可以解释为什么Camel表现得像这样吗？
答案 0 :(得分：2)
经过大量挖掘后，解决方案变得相当微不足道。该路由生成自定义的exchangeId，以简化针对客户端请求的交换跟踪。在路径结束时，结果是当交换被销毁（从机上存储库中删除）时，交换机的关键：值映射：存储库中的交换不包含自定义的exchangeId，并且由于显而易见的原因，不会删除已完成的交换。
这似乎是使用聚合策略的副作用。如果没有这个，交换将按预期删除。
简而言之，这是用户错误......