Hello Justin,
Could you please share your point of view regarding. "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 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". " Is it safe to ignore these messages, or is there anything else relevant to do from your perspective. Thanks a lot. Jean-Noel Le mardi 12 novembre 2024 à 10:17 AM, jncdevl...@pm.me.INVALID <jncdevl...@pm.me.INVALID> a écrit : > Sorry, I don't have the <check-period> attribute in my configuration, this is > coming from the copy paste I did from the documentation to replicate my > configuration. > > > It is indeed. > > <cluster-connections> > > <cluster-connection name="my-cluster"> > > <connector-ref>primary-connector</connector-ref> > > <static-connectors> > > <connector-ref>backup-connector</connector-ref> > > </static-connectors> > > <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> > > > <cluster-connections> > > <cluster-connection name="my-cluster"> > > <connector-ref>backup-connector</connector-ref> > > <static-connectors> > > <connector-ref>primary-connector</connector-ref> > > </static-connectors> > > <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> > > > Jean-Noel > > Le mardi 12 novembre 2024 à 10:09 AM, jncdevl...@pm.me.INVALID > jncdevl...@pm.me.INVALID a écrit : > > > 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/list?users@activemq.apache.org:2017-9:log filter > > > > 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 jbert...@apache.org 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 jncdevl...@pm.me.invalid 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: users-unsubscr...@activemq.apache.org > > > > For additional commands, e-mail: users-h...@activemq.apache.org > > > > For further information, visit: https://activemq.apache.org/contact > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org > > For additional commands, e-mail: users-h...@activemq.apache.org > > For further information, visit: https://activemq.apache.org/contact > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org > For additional commands, e-mail: users-h...@activemq.apache.org > For further information, visit: https://activemq.apache.org/contact --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org For additional commands, e-mail: users-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
