[
https://issues.apache.org/jira/browse/HADOOP-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15211143#comment-15211143
]
Harsh J commented on HADOOP-9567:
---------------------------------
Thanks [~subrotosanyal], that is indeed what handles it automatically for us
today. I was thinking more from a perspective where the app does not utilise
Hadoop or HBase IPCs. Some form of scheduled b/g daemon thread that could do
periodic renews, for each held LoginContext. There could be locking parts to
consider around this though, if someone uses getCurrentUser vs. getLoginUser.
I agree that in Hadoop's context we have it already covered, so we could also
close this out. Any direct users of UGI should self-ensure and call the
checkTGTAndReloginFromKeytab functionality themselves.
bq. but when you have all datanodes (or other client processes) started at the
same time, this can lead to a thundering herd effect, where all processes pile
on the KDC at the same time.
This seems like a separate issue to me (it wasn't my intention when filing
this). Perhaps such a check should only get added to DN login/re-login code,
cause in the UGI end it'd affect all users (even those who do not desire the
jitter)?
> Provide auto-renewal for keytab based logins
> --------------------------------------------
>
> Key: HADOOP-9567
> URL: https://issues.apache.org/jira/browse/HADOOP-9567
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Affects Versions: 2.0.0-alpha
> Reporter: Harsh J
> Assignee: Gary Helmling
> Priority: Minor
>
> We do a renewal for cached tickets (obtained via kinit before using a Hadoop
> application) but we explicitly seem to avoid doing a renewal for keytab based
> logins (done from within the client code) when we could do that as well via a
> similar thread.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
