为什么骆驼在inflightrepository中保留交换？

我的团队有一个运行（非常简单）的服务通过Apache骆驼运行，功能上一切都测试正常，但负载测试表明，该服务随着时间的推移会消耗内存。深入研究堆转储的结果是，内存消耗来自机库。看起来，通过路线发送的每一个交易所都被保留，但我们无法确定为什么在路线完成并且交易成功交付后应该保留交易所的任何理由。为什么骆驼在inflightrepository中保留交换？

我的团队对问题的最初反应是膝关节内存泄漏，但我不相信这是事实 - 我们只是有一个意想不到的行为 - 引用垃圾收集不会尝试处理它们。

难题在于它不仅仅是交换的一个副本，它似乎被保留，它是交换生命周期中保留的每一步，而路由并不特别复杂，它实现了分离 - 聚合路线，然后夸大了问题。

我们已经考虑添加一个组件来冲洗inflightrepository中的陈旧交换，但是这没有想到这一点。

任何人都可以解释为什么骆驼表现得像这样？

来源

2017-08-16 Julian

没有代码？我没有看到我的路线上的这种行为。 – Namphibian

如果不提供服务的完整代码 - 本身就有大量的代码，那么提供一些代码段就相当没有意义。这不是问题 - 骆驼保留机上交流的原因是什么？也许“骆驼什么时候从inflightrepository中删除交换？”将是一个更好的问题... – Julian

我还没有看到这种行为。 – Namphibian

经过相当多的挖掘后，解决方案变得非常简单。该路由生成自定义的exchangeId，以简化客户对请求进行交换的跟踪。结果是，在路由结束时，当交换被销毁（从机舱库中删除）时，存储库中的exchangeId：exchange的key：value映射不包含自定义exchangeId，并且由于显而易见的原因，不删除完成的交易所。

这似乎是使用聚合策略的副作用。没有这个交易所按预期被移除。

总之是用户错误...

来源

2017-11-15 15:22:44 Julian

根本没有用户错误。你的回答帮助我意识到了这个问题，但是骆驼有一个由exchangeId索引的机上仓库，而且我们可以简单地执行'exchange.setId（“mashedPotatoes”）'这并不会自动更新上述仓库是框架的错误，不是我们的。这种行为应该被封装。由于此问题导致内存泄漏，所以我们只是应用程序崩溃。 – henry700

为什么骆驼在inflightrepository中保留交换？

回答

相关问题