[
https://issues.apache.org/jira/browse/MAPREDUCE-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13202998#comment-13202998
]
Sanjay Radia commented on MAPREDUCE-3825:
-----------------------------------------
There is a difference between broken api and not being efficient and having
bugs.
- TokenCache is an internal impl and can be changed to work correctly with the
existing API. For example "TokenCache thinks the viewfs authority is a service
name so it tries to resolve it as a hostname:port tuple and fails." is the a
problem with TokenCache.
hostname-port was never a guarantee of FS URIs and so if tokencache made that
assumption it was a mistake.
- Viewfilesysgtem can be fixed to ignore duplicate mounts and tokens (if it
does not already)
Getting duplicate tokens is an ineffciency and I gave an example above in my
comment. You gave some additional examples in your comment.
Due to the inefficiency we can change things. However you conclusion that there
is not multi-token support or that things are broken in some fundamental ways
or that this is bug/major are incorrect. For example if a NN has two addreses
and two URI's the current impl and changes we may make will also result in
duplicate tokens.
> 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
>
> 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
