[
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/17/15 7:06 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 and a
subsequent 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 {{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.
> 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)
