[jira] [Resolved] (ACCUMULO-1578) Connector constructor doesn't need to fail-fast (maybe?)

["Christopher Tubbs (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ACCUMULO-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christopher Tubbs resolved ACCUMULO-1578.
-----------------------------------------
       Resolution: Won't Fix
    Fix Version/s:     (was: 1.8.0)

I'm going to close this. I think the change in behavior could be confusing. This can change in the new client API, where I do not expect to have a fail-fast (and, if there is one, it will be optional in the client factory).

> Connector constructor doesn't need to fail-fast (maybe?)
> --------------------------------------------------------
>
>                 Key: ACCUMULO-1578
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1578
>             Project: Accumulo
>          Issue Type: Task
>          Components: client
>            Reporter: Christopher Tubbs
>            Assignee: Christopher Tubbs
>   Original Estimate: 0.25h
>  Remaining Estimate: 0.25h
>
> Currently, when one instantiates a Connector from an Instance, with one's username and token, the Connector actually tries to reach out and authenticate those credentials, to provide early failure.
> Because this has some overhead, we explicitly check for the condition that the user is a system user (a tserver or the monitor, etc.), so that we don't fail early in these conditions (because we don't expect the system to be poorly configured or running in a bad state, such that it doesn't authenticate... and we don't care about causing an inconvenience to unauthorized servers by failing late).
> After some thought, I'm not sure that we should continue to fail fast. I'm not sure that it provides sufficient convenience for users to warrant the additional RPC calls. Besides, there's no guarantee, especially with the new pluggable authentication introduced in 1.5.0, that the credentials will still be valid later, even if the user were able to authenticate initially.
> As such, I propose we drop this check, and rely on authentication failures later (when work is actually initiated).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)