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

我们有4个ActiveMQ代理（每个在独立服务器上运行）在代理网络中设置。有大约60个生产者。生产者使用JDNI从Glassfish中查找ActiveMQ连接工厂。ActiveMQ故障转移传输 - 为什么有这么多的连接？

的ActiveMQ的URI在Glassfish的配置如下：

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消息传递使用相同的代码 - 因此，虽然生产者在创建会话和消息生成器的频率方面可能会有所不同，但它们都使用相同的代码，并且都只创建一个连接对象。

从阅读文档，我的理解是故障转移传输将打开一个经纪人的连接（在我们的案例中随机选择）。为什么我们看到这种连接流（在60ms内与每个经纪人有多个连接）？使用netstat我们可以看到这些连接。这是正常的吗？如果不是，有什么建议可能会导致这种情况？

来源

2014-12-31 sceaj

是否使用直接JMS或JMSTemplate等代码示例很有帮助。有没有使用PooledConnectionFactory？ –

它是直的JMS - 没有使用PooledConnectionFactory（至少不是直接） – sceaj

如果有XA连接工厂，那么您需要使用PooledConnectionFactory，否则它将一直断开/重新连接。你可以看到连接数量增长的管理主题之一（不记得哪一个） – stringy05

而无需ActiveMQ的记录等级升高有一定的空间来炒作，而是：

“对其他人来说是不太频繁” - 观察在不同情况下，不同的行为在这种情况下完全是自然的。如果负载不是完全分布在实例之间，它们在消息传递方面会有不同的表现。试想一下，你的一个节点占用了90％的触发输入，并单独完成大部分工作。该节点会承受更高的负载，并且会使用与其余节点完全不同的JMS资源。
“我的理解是，故障转移传输将打开一个经纪人的连接” - 这是完全正确的。只有在包装连接工厂要求打开新的物理连接时，故障转移才会起作用。在这种情况下，会为该请求创建恰好一个连接。
“为什么我们看到的连接此流” - 我敢肯定，这是由于其在项目中的缓冲池实现。您可以看到，已经建立了所有经纪人的连接（随机分布），同时指示多个新连接请求。

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

来源

2015-08-18 17:59:09

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

回答

相关问题