java glassfish jms activemq

java - Transporte de conmutación por error ActiveMQ-¿Por qué tantas conexiones?



glassfish jms (1)

Tenemos 4 brokers ActiveMQ (cada uno se ejecuta en un servidor separado) configurado en una red de brokers. Hay unos 60 productores. Los productores buscan la fábrica de conexiones ActiveMQ de Glassfish usando JDNI.

El URI ActiveMQ configurado en Glassfish es el siguiente:

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

Cada proceso productor realiza una búsqueda JNDI de javax.jms.ConnectionFactory y luego crea 1 javax.jms.Connection. A medida que el productor se ejecuta, creará periódicamente un javax.jms.Session y javax.jms.MessageProducer, enviará algunos mensajes a una cola y luego cerrará Session y MessageProducer.

Eso es todo fondo, ahora a mi pregunta. De algunos, pero no de todos los productores, veremos una secuencia de salida de registro como la siguiente:

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]

Para algunos de los productores veremos esta salida cada 10 minutos, para otros es menos frecuente. Aún más confuso es que todos estos productores usan código idéntico para la mensajería JMS, por lo que mientras los productores pueden variar la frecuencia con la que crean sesiones y productores de mensajes, todos usan el mismo código y todos crean solo 1 objeto de conexión.

De la lectura de la documentación, entiendo que el transporte de conmutación por error abriría una conexión con uno de los corredores (selección aleatoria en nuestro caso). ¿Por qué vemos este flujo de conexiones (conexiones múltiples para cada uno de los corredores dentro de 60 ms)? Usando netstat podemos ver estas conexiones. ¿Esto es normal? Si no, ¿alguna sugerencia sobre qué podría estar causando esto?

Sin tener los niveles de registro de activeMQ elevados, hay espacio para la especulación, pero:

  • "para otros es menos frecuente" : observar diferentes comportamientos en diferentes casos en este caso es completamente natural. Si la carga no está perfectamente distribuida entre las instancias, se comportarán de manera diferente cuando se trata de mensajes. Solo imagine que uno de sus nodos recoge el 90% de las entradas de activación y hace la mayor parte del trabajo solo. Ese nodo estaría bajo una carga mucho más alta y usaría sus recursos JMS de manera totalmente diferente al resto de los nodos.
  • "Tengo entendido que el transporte de conmutación por error abriría una conexión con uno de los corredores" . Eso es completamente cierto. La conmutación por error entrará en juego solo si la conexión de conexión de la fábrica solicita que se abra una nueva conexión física. En este caso, se creará exactamente una conexión para esa solicitud.
  • "¿Por qué vemos este flujo de conexiones?" . Estoy bastante seguro de que esto se debe a que tiene una implementación de agrupación en su proyecto. Puede ver que hay conexiones establecidas para todos sus corredores (distribuidas al azar), que indican múltiples solicitudes de nuevas conexiones al mismo tiempo.

Al aumentar el nivel de registro en su aplicación, podrá ver exactamente qué capa inicia esto y por qué motivo. Las posibles razones son: "todas las conexiones expiraron y el grupo restaura el conteo de minIdleConnection al mínimo"; "alguna solicitud entrante en su aplicación requiere que se envíen muchos mensajes a la vez, por lo que su grupo los crea".