[
https://issues.apache.org/jira/browse/ARTEMIS-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375873#comment-17375873
]
Justin Bertram commented on ARTEMIS-3377:
-----------------------------------------
As Gary mentioned, this is the expected behavior. The core client is informed
of the cluster topology (including the backup) when it makes a successful
connection. Therefore, when the client connects to broker A it is informed that
B is the backup. The client knows nothing of C at this point. If broker A fails
then B will become live and the client will connect to B. At this same time C
will become the backup to B and the client will be informed that C is now the
backup to B so that when B fails the client will connect to C. Since both A and
B are being killed before C joins the party so to speak then the client doesn't
know it should connect to C and it will simply try to connect to A & B forever
since you've configured {{reconnectAttempts=-1}}.
Regarding your work-arounds...
bq. Use only Live and Backup nodes, avoiding brokers in state "Waiting to
become backup node".
This is what I would recommend. Although it is technically possible to
configure a waiting-to-become-backup-node it is often not very useful.
bq. Avoid reconnectAttempts=-1 (or setting a small number of attempts) and let
the application recreate the connection.
I would also recommend this to give the client the best chances of reconnecting
no matter what the circumstance. The client has no guarantee regarding the
state of the brokers. The brokers could potentially go up and down in all sorts
of bizarre ways that preclude normal fail-over (just as in this use-case). The
client should be able to deal with connection failures or at least use a
framework (e.g. Camel, Spring, etc.) that can.
> Client does not reconnect after failover when both Live and Backup brokers
> are killed
> -------------------------------------------------------------------------------------
>
> Key: ARTEMIS-3377
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3377
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 2.16.0
> Reporter: Apache Dev
> Priority: Major
>
> Scenario:
> * 3 brokers configured in Live/Backup with shared DB storage
> ** Broker A is "Live"
> ** Broker B is "Backup Announced"
> ** Broker C is "Waiting to become backup node"
> * Client is connected using the following HA URL:
> **
> (tcp://activemq:61616,tcp://activemq2:61616,tcp://activemq3:61616)?ha=true&reconnectAttempts=-1&initialConnectAttempts=-1&consumerWindowSize=1048576&minLargeMessageSize=2147483647
> * Both Broker A and Broker B are killed
> * Broker C becomes Live
> * Client does not reconnect to Broker C automatically even if configured
> with "reconnectAttempts=-1"
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
