hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arpit Agarwal (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HADOOP-11567) Refresh HTTP Authentication secret without restarting the server
Date Thu, 16 Jul 2015 23:56:05 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-11567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14630557#comment-14630557
] 

Arpit Agarwal edited comment on HADOOP-11567 at 7/16/15 11:55 PM:
------------------------------------------------------------------

Hi Benoy, thanks for addressing the feedback. I was not familiar with the _try with resources_,
thanks for the clarification.

bq. pollForSecretChange will read the file only if the secret file is changed.
Got it. It looked like each call performed a filesystem operation to determine if the file
has changed but I looked at the {{AbstractWatchKey#pollEvents}} implementation and it uses
all in-memory ops so that is good.

Couple of remaining comments:
bq. Please note that fields involved are volatile. So the changes are visible across threads
and “happens before” guarantee of volatile variable makes sure that changes are visible
in the same order. 
The test and reset of {{rolloutRequired}} and {{rollbackRequired}} are not atomic though.
Multiple threads could get through each {{if}} block the second thread may throw away the
old secret. At least the {{if}} blocks must be synchronized. We can use double-checked locking
with a volatile state flag to avoid locking overhead in the common case.

Also we can allow using a human readable timestamp for the effectivetimeinmillis configuration
in addition to a unix timestamp. The former will be easier for manual configuration.


was (Author: arpitagarwal):
Hi Benoy, thanks for addressing the feedback. I was not familiar with the _try with resources_,
thanks for the clarification.

bq. pollForSecretChange will read the file only if the secret file is changed.
Got it. It looked like each call performed a filesystem operation to determine if the file
has changed but I looked at the pollForSecretChange implementation and it uses all in-memory
ops so that is good.

Couple of remaining comments:
bq. Please note that fields involved are volatile. So the changes are visible across threads
and “happens before” guarantee of volatile variable makes sure that changes are visible
in the same order. 
The test and reset of {{rolloutRequired}} and {{rollbackRequired}} are not atomic though.
Multiple threads could get through each {{if}} block the second thread may throw away the
old secret. At least the {{if}} blocks must be synchronized. We can use double-checked locking
with a volatile state flag to avoid locking overhead in the common case.

Also we can allow using a human readable timestamp for the effectivetimeinmillis configuration
in addition to a unix timestamp. The former will be easier for manual configuration.

> Refresh HTTP Authentication secret without restarting the server
> ----------------------------------------------------------------
>
>                 Key: HADOOP-11567
>                 URL: https://issues.apache.org/jira/browse/HADOOP-11567
>             Project: Hadoop Common
>          Issue Type: Improvement
>    Affects Versions: 2.6.0
>            Reporter: Benoy Antony
>            Assignee: Benoy Antony
>              Labels: BB2015-05-TBR
>         Attachments: HADOOP-11567-001.patch, HADOOP-11567-002.patch, HADOOP-11567-003.patch
>
>
> The _AuthenticationFilter_ uses the secret read from a file specified via hadoop.http.authentication.signature.secret.file
to sign the cookie containing user authentication information.
> The secret is read only during initialization and hence needs a restart to update the
secret.
> ZKSignerSecretProvider can be used to rotate the secrets without restarting the servers,
but it needs a zookeeper setup.
> The jira is to refresh secret by updating the file.



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

Mime
View raw message