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

sce*_*eaj 20 java activemq-classic jms glassfish

我们在经纪人网络中设置了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
Run Code Online (Sandbox Code Playgroud)

每个生成器进程执行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]
Run Code Online (Sandbox Code Playgroud)

对于一些生产者,我们每隔10分钟就会看到这个产出 - 对于其他生产者来说,它的频率较低.更令人困惑的是,所有这些生产者都使用相同的代码进行JMS消息传递 - 因此,虽然生产者可能会在创建会话和消息生成器的频率方面有所不同,但它们都使用相同的代码,并且所有生成器只创建一个连接对象.

通过阅读文档,我的理解是故障转移传输将打开与1个代理的连接(在我们的例子中随机选择).为什么我们看到这个连接流(在60ms内与每个代理的多个连接)?使用netstat我们可以看到这些连接.这是正常的吗?如果没有,有什么可能导致这个的建议吗?

Ger*_*cso 1

如果没有提高 activeMQ 日志级别,则有一些猜测的空间,但是:

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

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