ActiveMQ отказоустойчивый транспорт - Почему так много соединений?

У нас есть 4 брокера ActiveMQ (каждый работает на отдельном сервере) в сети брокеров. Там около 60 производителей. Производители ищут подключение ActiveMQ factory от Glassfish с помощью JDNI.

URI ActiveMQ, настроенный в Glassfish, выглядит следующим образом:

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

Каждый процесс производителя выполняет JNDI-поиск javax.jms.ConnectionFactory, а затем создает 1 javax.jms.Connection. По мере запуска продюсера будет периодически создаваться javax.jms.Session и javax.jms.MessageProducer, отправлять сообщения в очередь, а затем закрывать сеанс и 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 - поэтому, хотя производители могут варьироваться в зависимости от того, как часто они создают сеансы и создатели сообщений, все они используют один и тот же код, и все создают только один объект соединения.

Из-за чтения документации, я понимаю, что переход на другой ресурс откроет соединение с одним из брокеров (случайный выбор в нашем случае). Почему мы видим этот поток соединений (несколько соединений с каждым из брокеров в течение 60 мс)? Используя netstat, мы можем видеть эти соединения. Это нормально? Если нет, какие-либо предложения относительно того, что может быть причиной этого?

Ответ 1

Без наличия активных уровней logMQ есть место для спекуляции, но:

"для других это реже". Наблюдение различного поведения в разных случаях в этом случае является вполне естественным. Если загрузка не может быть распределена между экземплярами, они будут вести себя по-разному, когда дело доходит до обмена сообщениями. Представьте себе, что один из ваших узлов собирает 90% инициирующих входов и выполняет большую часть работы в одиночку. Этот node будет находиться на гораздо более высокой нагрузке и будет использовать свои ресурсы JMS полностью иначе, чем остальные узлы.
"Я понимаю, что переход на другой ресурс откроет связь с одним из брокеров". Это совершенно верно. Отказоустойчивость придет в игру только в том случае, если обертывание connectionFactory запрашивает новое физическое соединение для открытия. В этом случае для этого запроса будет создано ровно одно соединение.
"Почему мы видим этот поток соединений" - я уверен, что это связано с реализацией объединения в вашем проекте. Вы можете видеть, что эти соединения установлены для всех ваших брокеров (случайным образом распределены), указывая одновременно на несколько запросов на новые подключения.

Увеличивая лог-уровень в вашем приложении, вы сможете точно определить, какой слой инициирует это и по какой причине. Возможные причины: "все соединения были истекли, и пул восстанавливает минимальное количество MINIdleConnection до минимума"; "для входящего запроса в вашем приложении требуется много сообщений для отправки сразу, поэтому ваш пул создает их".