Nos estamos conectando con algunos clientes JMS a corredores ActiveMQ Artemis (v2.14.0) que se ejecutan en una configuración de clúster. Hoy, hemos notado que los clientes se conectan al aceptador dedicado a las comunicaciones del clúster y nos preguntamos por qué sucede esto.
Aquí están los broker.xmlfragmentos relevantes:
<configuration xmlns="urn:activemq" xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:activemq /schema/artemis-configuration.xsd">
<core xmlns="urn:activemq:core" xsi:schemaLocation="urn:activemq:core ">
[…]
<connectors>
<connector name="netty-connector">tcp://${ipv4addr:localhost}:61618?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;useEpoll=true</connector>
</connectors>
<acceptors>
<!-- Acceptor for every supported protocol -->
<acceptor name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;connectionsAllowed=10000</acceptor>
<!-- AMQP Acceptor. Listens on default AMQP port for AMQP traffic.-->
<acceptor name="amqp">tcp://0.0.0.0:5672?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=AMQP;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpMinLargeMessageSize=102400;amqpDuplicateDetection=true</acceptor>
<!-- STOMP Acceptor. -->
<acceptor name="stomp">tcp://0.0.0.0:61613?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=STOMP;useEpoll=true</acceptor>
<!-- HornetQ Compatibility Acceptor. Enables HornetQ Core and STOMP for legacy HornetQ clients. -->
<acceptor name="hornetq">tcp://0.0.0.0:5445?anycastPrefix=jms.queue.;multicastPrefix=jms.topic.;protocols=HORNETQ,STOMP;useEpoll=true</acceptor>
<!-- MQTT Acceptor -->
<acceptor name="mqtt">tcp://0.0.0.0:1883?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=MQTT;useEpoll=true</acceptor>
<acceptor name="netty-acceptor">tcp://0.0.0.0:61618?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;useEpoll=true</acceptor>
<acceptor name="artemis-tls">tcp://0.0.0.0:61617?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;amqpMinLargeMessageSize=102400;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;amqpDuplicateDetection=true;sslEnabled=true;keyStorePath=/var/lib/artemis/certs/keystore.jks;keyStorePassword=${keyStorePassword};enabledProtocols=TLSv1.2</acceptor>
</acceptors>
<broadcast-groups>
<broadcast-group name="cluster-broadcast-group">
<broadcast-period>5000</broadcast-period>
<jgroups-file>jgroups.xml</jgroups-file>
<jgroups-channel>active_broadcast_channel</jgroups-channel>
<connector-ref>netty-connector</connector-ref>
</broadcast-group>
</broadcast-groups>
<discovery-groups>
<discovery-group name="cluster-discovery-group">
<jgroups-file>jgroups.xml</jgroups-file>
<jgroups-channel>active_broadcast_channel</jgroups-channel>
<refresh-timeout>10000</refresh-timeout>
</discovery-group>
</discovery-groups>
<cluster-connections>
<cluster-connection name="artemis-cluster">
<connector-ref>netty-connector</connector-ref>
<retry-interval>500</retry-interval>
<use-duplicate-detection>true</use-duplicate-detection>
<message-load-balancing>STRICT</message-load-balancing>
<!-- <address>jms</address> -->
<max-hops>1</max-hops>
<discovery-group-ref discovery-group-name="cluster-discovery-group"/>
<!-- <forward-when-no-consumers>true</forward-when-no-consumers> -->
</cluster-connection>
</cluster-connections>
</core>
</configuration>
La intención es utilizar el puerto 61616 (TCP simple, aceptador artemis) y 61617 (TLS, aceptador artemis-tls) para las conexiones de clientes. Los corredores utilizarán el puerto 61618 (aceptador netty-acceptor) para las comunicaciones internas del clúster. Sin embargo, durante el descubrimiento de la topología, el intermediario envía el puerto 61618 al cliente (en lugar del puerto esperado 61616). Si bien esto funciona cuando todas las comunicaciones son TCP simples, las cosas se ponen raras cuando netty-acceptorse configura para TLS mientras que las conexiones del cliente no lo son. Luego, el cliente muestra mensajes como
2020-08-24 17:58:13,833 | WARN | Thread-1 (ActiveMQ-client-netty-threads) | i.n.c.ChannelInitializer | Failed to initialize a channel. Closing: [id: 0x5bb533bc]
java.lang.Exception: Failed to find a store at /var/lib/artemis/certs/truststore.jks
at org.apache.activemq.artemis.core.remoting.impl.ssl.SSLSupport.validateStoreURL(SSLSupport.java:278)
Entonces, el corredor pasa su configuración interna al cliente. ( /var/lib/artemis/certs/truststore.jksexiste solo en el contenedor Artemis).
¿Cómo podemos configurar el intermediario para conexiones de clúster y cliente dedicado y garantizar que el cliente nunca reciba el punto final del clúster? Además, ¿podemos configurar TLS de forma independiente para conexiones de cliente y de clúster? Los documentos no son realmente útiles aquí.
EDITAR
Repensar este problema lleva a una pregunta relacionada: ¿Cómo garantizar que los clientes que se conectan a través de TCP siempre reciban el puerto TCP durante el descubrimiento y que los clientes que se conectan a través de TLS reciban el puerto TLS?
ACTUALIZAR
Una mirada más cercana a laDocumentos de Artemisarevela esta explicación:
Aunque este valor se puede configurar en el servidor, el cliente lo descarga y lo utiliza.
Bien, eso explica un poco. Sin embargo, todavía no puedo entender cómo decirles a los clientes qué conector usar. En elRed Hat AMQ 7.2docs, el capítulo 6.3 dice
Un cliente, o incluso el propio intermediario, haría referencia al conector anterior al realizar una conexión TCP a la IP y el puerto especificados, 10.10.10.2:61617.
sugiriendo que el cliente haga coincidir la dirección IP y los puertos para encontrar un conector apropiado. Sin embargo, esto no parece funcionar con Artemis v2.14.0.