[
https://issues.apache.org/jira/browse/KUDU-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serbin reassigned KUDU-2586:
-----------------------------------
Assignee: (was: Alexey Serbin)
> Refactor ConnectToClusterRpc to handle FATAL_INVALID_AUTHENTICATION_TOKEN
> -------------------------------------------------------------------------
>
> Key: KUDU-2586
> URL: https://issues.apache.org/jira/browse/KUDU-2586
> Project: Kudu
> Issue Type: Improvement
> Components: client, security
> Affects Versions: 1.8.0
> Reporter: Alexey Serbin
> Priority: Major
>
> Current implementation of the {{ConnectToClusterRpc::SingleNodeCallback()}}
> method does not handle {{FATAL_INVALID_AUTHENTICATION_TOKEN}} error code,
> relying on handling that in {{KuduClient::Data::SyncLeaderMasterRpc()}}. As
> it turned out, that's not enough: see KUDU-2058.
> In short, current authn token should be removed from the messenger after upon
> receiving {{FATAL_INVALID_AUTHENTICATION_TOKEN}} error code in response from
> any master. A new token should be automatically acquired (if primary
> credentials are present) on next attempt to connect to the cluster.
> Also, it would be nice to refactor
> {{KuduClient::Data::SyncLeaderMasterRpc()}} regarding handling of various
> error codes. Additionally, it's necessary to revise the logic of
> setting/resetting the {{KuduClient::Data::master_proxy_}} member upon
> receiving non-OK result status in
> {{KuduClient::Data::ConnectedToClusterCb()}}; e.g. whether it's worth keep
> the old proxy to the master server if receiving {{NOT_THE_LEADER}} error
> response code while trying to connect to it. Maybe, the latter approach
> would automatically straighten things up without necessity to handle
> {{FATAL_INVALID_AUTHENTICATION_TOKEN}} by {{ConnectToClusterRpc}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
