Wir stellen über einige JMS-Clients eine Verbindung zu ActiveMQ Artemis-Brokern (v2.14.0) her, die in einer Clusterkonfiguration ausgeführt werden. Heute haben wir festgestellt, dass die Clients eine Verbindung zu dem Akzeptor herstellen, der für die Clusterkommunikation vorgesehen ist, und fragen uns, warum das passiert.
Hier sind die relevanten broker.xmlAusschnitte:
<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>
Es ist beabsichtigt, Port 61616 (einfaches TCP, Akzeptor artemis) und 61617 (TLS, Akzeptor artemis-tls) für Clientverbindungen zu verwenden. Die Broker sollen Port 61618 (Akzeptor) für netty-acceptorclusterinterne Kommunikation verwenden. Während der Topologieerkennung sendet der Broker jedoch Port 61618 an den Client zurück (anstelle des erwarteten Ports 61616). Dies funktioniert zwar, wenn die gesamte Kommunikation einfaches TCP ist, aber es wird seltsam, wenn netty-acceptorfür TLS konfiguriert ist, während Clientverbindungen nicht konfiguriert sind. Der Client zeigt dann Nachrichten wie
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)
Daher übergibt der Broker seine interne Konfiguration an den Client. ( /var/lib/artemis/certs/truststore.jksexistiert nur im Artemis-Container.)
Wie können wir den Broker für dedizierte Client- und Clusterverbindungen konfigurieren und sicherstellen, dass der Client niemals den Clusterendpunkt empfängt? Können wir TLS außerdem unabhängig für Client- und Clusterverbindungen konfigurieren? Die Dokumentation ist hier nicht wirklich hilfreich.
BEARBEITEN
Das erneute Überdenken dieses Problems führt zu einer verwandten Frage: Wie kann sichergestellt werden, dass Clients, die eine Verbindung über TCP herstellen, bei der Erkennung immer den TCP-Port erhalten und Clients, die eine Verbindung über TLS herstellen, den TLS-Port erhalten?
AKTUALISIEREN
Ein genauerer Blick auf dieArtemis-Dokumenteergibt diese Erklärung:
Obwohl dieser Wert auf dem Server konfiguriert werden kann, wird er vom Client heruntergeladen und verwendet.
Okay, das erklärt ein bisschen. Ich kann jedoch immer noch nicht herausfinden, wie ich den Clients sagen kann, welchen Connector sie verwenden sollen. ImRedHat AMQ 7.2docs, Kapitel 6.3 sagt
Auf den obigen Connector würde von einem Client oder sogar dem Broker selbst verwiesen, wenn eine TCP-Verbindung mit der angegebenen IP und dem angegebenen Port 10.10.10.2:61617 hergestellt wird.
schlägt vor, dass der Client IP-Adresse und Ports abgleicht, um einen geeigneten Connector zu finden. Dies scheint jedoch mit Artemis v2.14.0 nicht zu funktionieren.