[jira] [Work logged] (ARTEMIS-3496) Replica connection to its live should fail fast

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARTEMIS-3496?focusedWorklogId=661487&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-661487 ]

ASF GitHub Bot logged work on ARTEMIS-3496:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 07/Oct/21 09:58
            Start Date: 07/Oct/21 09:58
    Worklog Time Spent: 10m 
      Work Description: gtully commented on pull request #3771:
URL: https://github.com/apache/activemq-artemis/pull/3771#issuecomment-937639379


   I guess a test would be best, but this looks a trivial fix and it is important for time to recover from failure. I would like to see this in 2.19.0.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: gitbox-unsubscribe@activemq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 661487)
    Time Spent: 1h 20m  (was: 1h 10m)

> 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
>          Time Spent: 1h 20m
>  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.3.4#803005)