Estamos nos conectando com alguns clientes JMS a corretores ActiveMQ Artemis (v2.14.0) em execução em uma configuração de cluster. Hoje notamos que os clientes se conectam ao aceitador dedicado às comunicações do cluster e estão se perguntando por que isso acontece.
Aqui estão os broker.xmltrechos 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>
A intenção é usar as portas 61616 (TCP simples, aceitador artemis) e 61617 (TLS, aceitador artemis-tls) para conexões de clientes. Os corretores devem usar a porta 61618 (aceitador netty-acceptor) para comunicações internas do cluster. Entretanto, durante a descoberta da topologia, o broker envia a porta 61618 de volta ao cliente (em vez da porta 61616 esperada). Embora isso funcione quando todas as comunicações são TCP simples, as coisas ficam estranhas quando netty-acceptoré configurado para TLS, enquanto as conexões do cliente não são. O cliente então mostra mensagens 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)
Assim, a corretora passa sua configuração interna para o cliente. ( /var/lib/artemis/certs/truststore.jksexiste apenas no contêiner Artemis.)
Como podemos configurar o broker para conexões dedicadas de cliente e cluster e garantir que o cliente nunca receba o endpoint do cluster? Além disso, podemos configurar o TLS de forma independente para conexões de cliente e cluster? Os documentos não são realmente úteis aqui.
EDITAR
Repensar esse problema leva a uma questão relacionada: como garantir que os clientes que se conectam via TCP sempre recebam a porta TCP durante a descoberta e que os clientes que se conectam via TLS recebam a porta TLS?
ATUALIZAR
Um olhar mais atento paraDocumentos de Artemisrevela esta explicação:
Embora esse valor possa ser configurado no servidor, ele é baixado e usado pelo cliente.
Ok, isso explica um pouco. No entanto, ainda não consigo descobrir como informar aos clientes qual conector usar. NoRedHat AMQ 7.2documentos, capítulo 6.3 diz
O conector acima seria referenciado por um cliente, ou mesmo pelo próprio broker, ao fazer uma conexão TCP com o IP e porta especificados, 10.10.10.2:61617.
sugerindo que o cliente corresponda ao endereço IP e às portas para encontrar um conector apropriado. No entanto, isso parece não funcionar com o Artemis v2.14.0.