ActiveMQ 故障转移传输 - 为什么有这么多连接？

java glassfish jms activemq

2022-09-02 04:54:14

我们在代理网络中设置了 4 个 ActiveMQ 代理（每个代理在单独的服务器上运行）。大约有60个生产者。生产者使用JDNI从Glassfish查找ActiveMQ连接工厂。

在 Glassfish 中配置的 ActiveMQ URI 如下所示：

failover:(tcp://phxgapm01:61616,tcp://phxgapm02:61616,tcp://phxgapm03:61616,tcp://phxgapm04:61616)?randomize=true&backup=false&maxReconnectAttempts=8

每个生产者进程对 javax.jms.ConnectionFactory 进行 JNDI 查找，然后创建 1 个 javax.jms.Connection。当创建器运行时，它将定期创建一个javax.jms.Session和javax.jms.MessageProducer，将一些消息发送到队列，然后关闭Session和MessageProducer。

这就是所有的背景 - 现在回答我的问题。从一些（但不是全部）生产者那里，我们将看到如下所示的日志输出流：

2014-12-30 21:07:06,534 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm03:61616 - [ActiveMQ Task-1]
2014-12-30 21:07:06,538 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1]
2014-12-30 21:07:06,544 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm02:61616 - [ActiveMQ Task-1]
2014-12-30 21:07:06,548 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1]
2014-12-30 21:07:06,552 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm01:61616 - [ActiveMQ Task-1]
2014-12-30 21:07:06,556 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm02:61616 - [ActiveMQ Task-1]
2014-12-30 21:07:06,561 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm02:61616 - [ActiveMQ Task-1]
2014-12-30 21:07:06,565 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm01:61616 - [ActiveMQ Task-1]
2014-12-30 21:07:06,568 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm02:61616 - [ActiveMQ Task-1]
2014-12-30 21:07:06,572 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1]
2014-12-30 21:07:06,577 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm03:61616 - [ActiveMQ Task-1]
2014-12-30 21:07:06,581 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1]
2014-12-30 21:07:06,586 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm01:61616 - [ActiveMQ Task-1]
2014-12-30 21:07:06,590 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm03:61616 - [ActiveMQ Task-1]
2014-12-30 21:07:06,594 INFO  FailoverTransport    - Successfully connected to tcp://phxgapm04:61616 - [ActiveMQ Task-1]

对于某些生产者，我们将每10分钟看到一次此输出 - 对于其他人，它的频率较低。更令人困惑的是，所有这些生产者都使用相同的代码进行JMS消息传递 - 因此，尽管生产者在创建会话和消息生产者的频率上可能会有所不同，但它们都使用相同的代码，并且都只创建1个连接对象。

通过阅读文档，我的理解是故障转移传输将打开与其中 1 个代理的连接（在本例中为随机选择）。为什么我们会看到这种连接流（在 60 毫秒内与每个代理建立多个连接）？使用netstat，我们可以看到这些连接。这正常吗？如果没有，关于可能导致这种情况的任何建议？

答案 1

如果不提高 activeMQ 对数级别，则有一些推测的余地，但是：

“对于其他人来说，它不那么频繁” - 在这种情况下，在不同情况下观察不同的行为是完全自然的。如果负载在实例之间没有完全分布，则在消息传递方面，它们的行为将有所不同。想象一下，你的一个节点拾取了90%的触发输入，并独自完成大部分工作。该节点将承受更高的负载，并且其 JMS 资源的使用方式与其他节点完全不同。
“我的理解是，故障转移传输将打开与其中 1 个代理的连接” - 这是完全正确的。仅当包装连接网站请求打开新的物理连接时，故障转移才会发挥作用。在这种情况下，将为该请求创建一个连接。
“为什么我们会看到这种连接流” - 我很确定这是由于在您的项目中有一个池化实现。您可以看到，有这些连接已建立到所有代理（随机分布），指示同时对新连接的多个请求。

通过增加应用程序中的日志级别，您将能够确切地看到哪个层启动此内容以及出于什么原因。可能的原因是：“所有连接都已过期，池将minIdleConnection计数恢复到最小值”;“应用程序中的某些传入请求需要一次发送大量消息，因此您的池会创建它们”。

答案 2