[
https://issues.apache.org/jira/browse/ARTEMIS-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17476264#comment-17476264
]
ASF subversion and git services commented on ARTEMIS-3496:
----------------------------------------------------------
Commit a57cd757f3e3ab6b07668ce964b55aa4fa5b0666 in activemq-artemis's branch
refs/heads/2.19.x from franz1981
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=a57cd75 ]
ARTEMIS-3496 Replica connection to its live should fail fast
(cherry picked from commit 1dc9d4f45589a1e8d2565e23fb8cd0321241f6e9)
> Replica connection to its live should fail fast
> -----------------------------------------------
>
> Key: ARTEMIS-3496
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3496
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Major
> Fix For: 2.20.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Both SharedNothingBackupActivation and ReplicationBackupActivation set
> session factory's cluster control reconnect attempts to 1, but the comment on
> the code for the former says:
> {code:java}
> //we should only try once, if its not there we should move on.
> {code}
> That doesn't look right, indeed, in case of failed cluster connection due to
> TTL, the additional attempt to reconnect slow down the whole failover process.
> As per the comment, to try connect just once, reconnect attempts should be
> set to 0.
> The weird thing is that the same session factory is created (along with the
> initial connection) with reconnectAttempts == 0 by
> ClusterController::connectToNodeInReplicatedCluster, before authorizing and
> starting the initial sync.
> Need an investigation to find out why it seems to be set to 1 from the
> original correct value.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
