Java Apache Servicemix-Heapspace问题-如何解决？

我们在生产中有一个apache servicemix实例（Version3.3.1），它运行我们的bpel流（使用apache ode 1.3.5）和一些驼峰代码（用于路由）。问题是，servicemix进程的使用的堆空间不断增加。最终它耗尽空间并崩溃。因此，我们必须每7-8天重新启动一次流程。（这很烦人）

当前进程的jvm内存配置如下所示
-Xms512M-Xmx2048M-XX:PermSize=512m-XX:MaxPermSize=1024m

我们有另一个servicemix实例，它具有相同的内存配置，但运行的负载稍小，在超过分配的堆空间之前，它会运行大约20-22天。显然，这一个上的较小负载有助于它的扩展运行

我的问题

是否有人在上述版本的apache servicemix中遇到过类似的问题？
（在初始级别，我想确定这是与容器相关的泄漏还是与应用程序相关的问题）

你如何着手解决这个问题？是否有一种方法，我可以申请找出问题？如果是这样的话，有人能列出同样的步骤吗？
（网络上的内存泄漏解决文章似乎更强调导致内存泄漏的理论，而不是解决内存泄漏应采取的步骤）

需要您的想法、建议和建议。

谢谢，

---

Arun Jolly

通常，当我们面对这个问题时，我们会生成一个堆转储文件，堆转储是Java进程在某个时间点的内存快照。持久化此数据有不同的格式，根据格式的不同，它可能包含不同的信息，但通常快照包含有关触发快照时堆中java对象和类的信息

有许多方法可以生成堆转储文件，但在您的情况下，您可以添加此参数，以便在发生

OutOfMemoryError

时自动生成堆转储文件：

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=[HeapDirPath]

因此，这个文件将允许您找出填充整个空间的对象，然后您将很容易地找出导致内存泄漏的代码

---

您可以使用来分析此类转储文件。

根据我的经验，ServiceMix 3的这种内存问题通常表示流中某个组件或端点的MEP处理存在问题。一些JBI组件、端点和服务保留一个挂起的交换列表，因此，如果其中一些消息交换模式无法正确终止，这些交换将永远不会从列表中删除

解决此问题的最佳方法是进行堆转储（例如使用jmap），然后查看其中的MessageExchange实现实例。您可能会发现一些保存在内存中的非常相似的消息交换。拥有这些属性后，您可以查看exchange属性，以找出导致问题的端点/组件

---

还有一些问题在以后的ServiceMix 3.x版本中得到了修复，这些问题可能是造成这种情况的原因。一定要在3.4.1版本上试一试，或者查看发行说明以了解最新版本。

谢谢Gert。关于我应该在堆转储中查找的MEP实现实例，您能更具体一点吗？我们使用的组件是嵌入式activemq、用于从队列路由到bpel流的camel组件、用于运行流的apache ode组件以及用于调用servicemix环境外部托管的web服务的流的http provider组件，每个受支持的MEP都有一个特定的MessageExchange实现类。我会寻找

org.apache.servicemix.jbi.messaging.InOnlyImpl/InOutImpl/noctionaloutimpl/robustinlyimpl

实例。或者，您也可以查看所有这些的底层值对象，它被称为

org.apache.servicemix.jbi.messaging.ExchangePacket

Hmm.。这是非常好的信息。只是出于好奇（我知道我们已经超出了这个问题的范围）…我已经对我们的设置进行了广泛的测试，我们从未错过任何我们推送到servicemix中的请求（即所有请求都成功地完成了整个流程）…那么，mep实现怎么会保留exchange对象呢？是否表示即使在传递消息之后，组件或终结点仍可能继续保留exchange对象？所有MEP都必须以“完成”或“错误”消息结束。例如：InOnly exchange首先以活动状态发送到目标端点-在处理后，该端点负责发回一条已完成的消息。如果目标端点没有使用该完成状态进行回复，则在前一个端点仍在等待完成消息到达时，从外部看起来一切都正常发生。也就是说，很多时候，问题出在JBI组件上，而不是你自己的代码上，所以你肯定想试试3.4.1版本，我想。是的。我已经下载了3.4.1版本，我们已经开始在其中测试我们的应用程序。但是，在我将容器从3.3.1迁移到3.4.1之前，我需要向我的产品涉众提出目前困扰我们的确切问题，并说服他们（用数据）了解迁移的必要性。非常感谢gert，您的输入非常有帮助，我们将带着结果返回本论坛。