[
https://issues.apache.org/jira/browse/HADOOP-18581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17652293#comment-17652293
]
ASF GitHub Bot commented on HADOOP-18581:
-----------------------------------------
cnauroth commented on code in PR #5248:
URL: https://github.com/apache/hadoop/pull/5248#discussion_r1057844215
##########
hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/Server.java:
##########
@@ -2206,7 +2206,25 @@ private void saslProcess(RpcSaslProto saslMessage)
AUDITLOG.warn(AUTH_FAILED_FOR + this.toString() + ":"
+ attemptingUser + " (" + e.getLocalizedMessage()
+ ") with true cause: (" + tce.getLocalizedMessage() + ")");
- throw tce;
+ if (!UserGroupInformation.getLoginUser().isLoginSuccess()) {
+ LOG.info("Initiating re-login from IPC Server");
+ if (UserGroupInformation.isLoginKeytabBased()) {
+ UserGroupInformation.getLoginUser().reloginFromKeytab();
Review Comment:
For keytab usage, there is `UserGroupInformation#forceReloginFromKeytab()`,
which always does the login regardless of time since last login. There is no
equivalent `forceReloginFromTicketCache()` though. We could add that, but
expanding the public API footprint of `UserGroupInformation` should not be
taken lightly. Ideally, I'd like to get a second opinion from one more
committer. I think it's the right thing to do. A drawback is that it's
potentially a dangerous API if used incorrectly, because it could spam the KDC.
> Handle Server KDC re-login when Server and Client run in same JVM.
> ------------------------------------------------------------------
>
> Key: HADOOP-18581
> URL: https://issues.apache.org/jira/browse/HADOOP-18581
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 3.1.1
> Reporter: Surendra Singh Lilhore
> Assignee: Surendra Singh Lilhore
> Priority: Major
> Labels: pull-request-available
>
> Handle re-login in Server when client, server running in same JVM and client
> trying to re-login, but it fails.
> For example, NameNode is server but in same JVM journal node client also
> running to push to edit logs. When JN client try to re-login and it fails, it
> will destroy server service ticket also and NameNode not able to server
> client request. We can see the below error logs in NameNode log file.
>
> {noformat}
> Auth failed for x.x.x.x:42199:null (GSS initiate failed) with true cause:
> (GSS initiate failed)
> Auth failed for x.x.x.x:42199:null (GSS initiate failed) with true cause:
> (GSS initiate failed)
> Auth failed for x.x.x.x:42199:null (GSS initiate failed) with true cause:
> (GSS initiate failed){noformat}
> Same discussion happened in HADOOP-17996.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
