这是可耻的，但我们知道有一些activemq连接泄漏。代码很旧，有很多曲折，这使得发现泄漏流非常困难。
我们从批处理机器中解雇许多短叶工作。我们知道并非所有路径都正确关闭activemq连接。当连接未关闭但作业终止时，activemq会保持该连接一段时间。最终，有些关键应用程序会受到影响，因为activemq max连接限制超过了。
是否可以设置连接名称或其他标识信息，以便在activemq的日志文件中显示未正确关闭的连接。这将告诉我们需要检查哪些日志文件。大量的工作使得很难找出导致问题的确切工作。但是，一旦我们知道了这项工作，我们就可以从日志中推断出足够的信息来查找和修复连接泄漏。
现在我们所看到的是从哪个连接发起的IP地址，并且由于所有作业都来自同一台机器，因此无法找出导致问题的原因
答案 0 :(得分：0)
如果您在连接URL中添加jms.clientID=something并在conf / log4j.properties中启用DEBUG日志记录，您将在AMQ上的调试日志中获取客户端ID。然后，您可以编写一些内容来分析您的日志，并找到给定clientID的AMQ ID，并以相应的方式匹配日志。
如果您的流程确实存在，那么您的连接应该在那时消失（即，如果没有流程可以保持连接，则无法保持连接。）
如果您在Linux上运行，则可以执行netstat -anp | grep 61616（或你的AMQ端口是什么）看看哪些PID仍然与AMQ有连接，然后是另一个ps看看这些进程是什么。