[
https://issues.apache.org/jira/browse/HADOOP-12178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14626181#comment-14626181
]
Steve Loughran commented on HADOOP-12178:
-----------------------------------------
I looked at the code and thought, yes, we should be rethrowing non IOEs, as
they represent different failure modes and the sasl client logic would be
implicitly passed
It comes down to this: the reason the exceptions are being caught and processed
is the assumption that all exceptions raised in the {{doAs}} clause indicate a
problem with SASL, and that a new attempt should be made. I don't believe
that's the case. things like NPEs, class-loading problems, etc, are not
suitable to fallback, so should just be rethrown.
my first pass impl actually did
{code}
} catch (RuntimeException ex) {
throw e;
} catch (IOException ex) {
...
}
{code}
Doing it this way guarantees that the rethrown exception retains the existing
type and doesn't get lost in an IOE chain.
The current patch doesn' t need to do that, anything != IOE is impliciatly
handled. The check for rpcclient == null is there to handle the case that the
construction process fails for some other reason. Given the constructor doesn't
include IOE as an exception, I actually think the case of IOE+rpcclient==null
isn't possible, but felt that keeping the check in there would only be another
safety option.
Do you believe that there are some exceptions which can be raised during SASL
setup which are not IOEs, yet for which the SASL handling can kick in?
> NPE during handling of SASL setup if problem with SASL resolver class
> ---------------------------------------------------------------------
>
> Key: HADOOP-12178
> URL: https://issues.apache.org/jira/browse/HADOOP-12178
> Project: Hadoop Common
> Issue Type: Bug
> Components: ipc
> Affects Versions: 2.7.1
> Reporter: Steve Loughran
> Assignee: Steve Loughran
> Priority: Minor
> Attachments: HADOOP-12178-001.patch
>
>
> If there's any problem in the constructor of {{SaslRpcClient}}, then IPC
> Client throws an NPE rather than forwarding the stack trace. This is because
> the exception handler assumes that {{saslRpcClient}} is not null, that the
> exception is related to the SASL setup itself.
> The exception handler needs to check for {{saslRpcClient}} being null, and if
> so, rethrow the exception
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
