[
https://issues.apache.org/jira/browse/HADOOP-13081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15400072#comment-15400072
]
Chris Nauroth commented on HADOOP-13081:
----------------------------------------
Nice catch on cloning the Hadoop {{Credentials}} instances! Those are mutable.
{code}
Set<Object> set = new HashSet<>(old.size());
{code}
I assume this was intended to size the new set identical to the old one to
prevent reallocations while adding elements. Unfortunately, the constructor
argument is the initial capacity, not the expected size. With the default load
factor of 0.75, that means passing the old set's size actually is highly likely
to cause one reallocation while adding elements.
I think using the no-args constructor is acceptable here, given that the sets
are expected to be small. If you feel it's really important to control the
size, then you could use something like Guava's logic:
https://github.com/google/guava/blob/v11.0.2/guava/src/com/google/common/collect/Maps.java#L106-L120
(Please don't call Guava directly here though. We're starting to try to limit
our dependency on it.)
I think this will be ready to go after addressing that and the last round of
pre-commit nitpicks.
> add the ability to create multiple UGIs/subjects from one kerberos login
> ------------------------------------------------------------------------
>
> Key: HADOOP-13081
> URL: https://issues.apache.org/jira/browse/HADOOP-13081
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Attachments: HADOOP-13081.01.patch, HADOOP-13081.02.patch,
> HADOOP-13081.02.patch, HADOOP-13081.patch
>
>
> We have a scenario where we log in with kerberos as a certain user for some
> tasks, but also want to add tokens to the resulting UGI that would be
> specific to each task. We don't want to authenticate with kerberos for every
> task.
> I am not sure how this can be accomplished with the existing UGI interface.
> Perhaps some clone method would be helpful, similar to createProxyUser minus
> the proxy stuff; or it could just relogin anew from ticket cache.
> getUGIFromTicketCache seems like the best option in existing code, but there
> doesn't appear to be a consistent way of handling ticket cache location - the
> above method, that I only see called in test, is using a config setting that
> is not used anywhere else, and the env variable for the location that is used
> in the main ticket cache related methods is not set uniformly on all paths -
> therefore, trying to find the correct ticket cache and passing it via the
> config setting to getUGIFromTicketCache seems even hackier than doing the
> clone via reflection ;) Moreover, getUGIFromTicketCache ignores the user
> parameter on the main path - it logs a warning for multiple principals and
> then logs in with first available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
