[
https://issues.apache.org/jira/browse/MAPREDUCE-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13205209#comment-13205209
]
Sanjay Radia commented on MAPREDUCE-3825:
-----------------------------------------
Solution 2 ( the one with a single API: void
FileSystem#addDelegationTokens(renewer, credentials) ) has the advantage that
the caller does not need to have the full list of file system and paths in
order to eliminate duplicate tokens. (Vinod tell me that the MR is more like
that.) Solution 1 requires that the caller has the full list of file systems
and then gets all the embedded file system and then eliminates the duplicate
file systems followed by obtaining delegate tokens.
I dislike the notion of passing in the credentials list parameter (actually a
set or tokens) to a FileSystem method which is then updated by the method - a
weird APi. But i can live with it.
> Need generalized multi-token filesystem support
> -----------------------------------------------
>
> Key: MAPREDUCE-3825
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-3825
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: security
> Affects Versions: 0.23.1, 0.24.0
> Reporter: Daryn Sharp
> Assignee: Daryn Sharp
> Attachments: MAPREDUCE-3825.patch
>
>
> This is the counterpart to HADOOP-7967. The token cache currently tries to
> assume a filesystem's token service key. The assumption generally worked
> while there was a one to one mapping of filesystem to token. With the advent
> of multi-token filesystems like viewfs, the token cache will try to use a
> service key (ie. for viewfs) that will never exist (because it really gets
> the mounted fs tokens).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
