Thank you Justin for your feedback, much appreciated.
> Can you provide your configuration files?
Primary configuration
<connectors>
<connector
name="primary-connector">tcp://myprimaryvm:61616sslEnabled=true;trustStorePath=broker.truststore;trustStorePassword=password;enabledProtocols=TLSv1.2;</connector>
<connector
name="backup-connector">tcp://mybackupvm:61616sslEnabled=true;trustStorePath=broker.truststore;trustStorePassword=password;enabledProtocols=TLSv1.2;</connector>
</connectors>
<cluster-connections>
<cluster-connection name="my-cluster">
<connector-ref>primary-connector</connector-ref>
<static-connectors>
<connector-ref>backup-connector</connector-ref>
</static-connectors>
<check-period>1000</check-period>
<retry-interval>60000</retry-interval>
<retry-interval-multiplier>1.0</retry-interval-multiplier>
<max-retry-interval>60000</max-retry-interval>
<initial-connect-attempts>-1</initial-connect-attempts>
<reconnect-attempts>-1</reconnect-attempts>
</cluster-connection>
</cluster-connections>
<ha-policy>
<shared-store>
<primary>
<failover-on-shutdown>true</failover-on-shutdown>
</primary>
</shared-store>
</ha-policy>
<acceptors>
<acceptor
name="artemis">tcp://0.0.0.0:61616?sslEnabled=true;keyStorePath=broker.keystore;keyStorePassword=password;enabledProtocols=TLSv1.2;[default
broker.xml values]</acceptor>
</acceptors>
Backup configuration
<connectors>
<connector
name="primary-connector">tcp://myprimaryvm:61616sslEnabled=true;trustStorePath=broker.truststore;trustStorePassword=password;enabledProtocols=TLSv1.2;</connector>
<connector
name="backup-connector">tcp://mybackupvm:61616sslEnabled=true;trustStorePath=broker.truststore;trustStorePassword=password;enabledProtocols=TLSv1.2;</connector>
</connectors>
<cluster-connections>
<cluster-connection name="my-cluster">
<connector-ref>backup-connector</connector-ref>
<static-connectors>
<connector-ref>primary-connector</connector-ref>
</static-connectors>
<check-period>1000</check-period>
<retry-interval>60000</retry-interval>
<retry-interval-multiplier>1.0</retry-interval-multiplier>
<max-retry-interval>60000</max-retry-interval>
<initial-connect-attempts>-1</initial-connect-attempts>
<reconnect-attempts>-1</reconnect-attempts>
</cluster-connection>
</cluster-connections>
<ha-policy>
<shared-store>
<backup>
<failover-on-shutdown>true</failover-on-shutdown>
<allow-failback>true</allow-failback>
</backup>
</shared-store>
</ha-policy>
<acceptors>
<acceptor
name="artemis">tcp://0.0.0.0:61616?sslEnabled=true;keyStorePath=broker.keystore;keyStorePassword=password;enabledProtocols=TLSv1.2;[default
broker.xml values]</acceptor>
</acceptors>
> Can you elaborate on exactly what you're doing to "test the connection with
> openssl"?
openssl s_client -connect mybackupvm:61616
> Depending on how you're trying to connect to the passive server it is
> indeed expected that it might not respond since it is, in fact, passive. To
> be clear, the passive broker is not meant to accept messaging connections.
Based on the "retry-interval" frequency, there is a connection tentative from
the primary server which turns out in this ERROR message AMQ214016 and flooding
logs.
That's why I have increased the interval to 60s.
The call comes from ActiveMQThreadFactory.java 118
The suppressed exception is
io.netty.handler.ssl.StacklessSSLHandshakeException: Connection closed while
SSL/TLS handshake was in progress.
at io.netty.handler.ssl.SslHandler.channelInactive
The thread related to user attempt to suppress the message is the following
https://lists.apache.org/[email protected]:2017-9:log%20filter
When not using SSL, there is a WARNING reported in logs at same pace reporting
"unblocking a blocking call that will never get a response".
Hence I'm wondering if I misconfigured something or if I can simply ignore /
filter these messages.
Thank you.
Jean-Noel
Envoyé avec la messagerie sécurisée Proton Mail.
Le lundi 11 novembre 2024 à 10:34 PM, Justin Bertram <[email protected]> a
écrit :
> > I have a simple cluster, shared store, defining a primary and a backup
>
> server with static connectors.
>
> Can you provide your configuration files?
>
> > When I test the connection with openssl from primary (VM1) to backup
>
> (VM2), it is indeed not happening. It works from VM2 to VM1.
>
> Can you elaborate on exactly what you're doing to "test the connection with
> openssl"?
>
> > Do I miss something regarding the connectors configuration ?
>
>
> It's not clear if you missed something in your configuration because it's
> not clear what the actual problem is.
>
> > Is it expected that the passive server does not respond ?
>
>
> Depending on how you're trying to connect to the passive server it is
> indeed expected that it might not respond since it is, in fact, passive. To
> be clear, the passive broker is not meant to accept messaging connections.
>
>
> Justin
>
> On Thu, Nov 7, 2024 at 2:17 PM [email protected] wrote:
>
> > Hello,
> > I have a simple cluster, shared store, defining a primary and a backup
> > server with static connectors.
> >
> > When enabling ssl, truststore is defined at connector level and keystore
> > at acceptor level, I can see the initial handshake happening in logs when I
> > start the backup server.
> >
> > What happens then, when the backup server reaches the phase "backup
> > announced", I keep receiving in primary server logs "AMQ214016 Failed to
> > create netty connection ClosedChannelException".
> >
> > When I test the connection with openssl from primary (VM1) to backup
> > (VM2), it is indeed not happening. It works from VM2 to VM1.
> >
> > When stopping the primary server, the backup server turns correctly into
> > primary and the openssl connection test works from VM1 to VM2.
> >
> > Do I miss something regarding the connectors configuration ? Is it
> > expected that the passive server does not respond ?
> >
> > I noticed in the archive a similar topic where the user wanted to filter
> > out these error messages.
> >
> > https://lists.apache.org/thread/o54shdyy4x7613cy33vtjhfkh0sb2mcp
> >
> > Thanks a lot for your support.
> >
> > Jean-Noel
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> > For further information, visit: https://activemq.apache.org/contact
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
