[
https://issues.apache.org/jira/browse/HBASE-27204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17567376#comment-17567376
]
Wellington Chevreuil commented on HBASE-27204:
----------------------------------------------
{quote}For me, I think the problem is in the implementation of your customized
sasl implementation... If client can just set itself as complete just after
getting the initial response, it should be considered as simple auth,
otherwise, at least it should check what the server returns to it...
{quote}
Just to clarify here, this is not {_}our implementation{_}, but the JDK one.
The only custom impl we have here, is for the SaslClientAuthenticationProvider,
which specifies the PLAIN SASL mechanism to be used, then the specific JVM sasl
implementation is chosen internally (the Sasl.createSaslClient call from
example below):
{noformat}
...
@Override
public SaslClient createClient(Configuration conf, InetAddress serverAddr,
SecurityInfo securityInfo, Token<? extends TokenIdentifier> token, boolean
fallbackAllowed,
Map<String, String> saslProps) throws IOException {
return Sasl.createSaslClient(new String[] { "PLAIN" }, null, null,
"default", saslProps, mySaslCallbackHandler);
}
...
{noformat}
That said, I'm not justifying the change introduced by HBASE-24579, just saying
that when using PLAIN sasl, as possible now after HBASE-23347, this unexpected
behaviour may occur even with the netty client rpc.
> BlockingRpcClient will hang for 20 seconds when SASL is enabled after
> finishing negotiation
> -------------------------------------------------------------------------------------------
>
> Key: HBASE-27204
> URL: https://issues.apache.org/jira/browse/HBASE-27204
> Project: HBase
> Issue Type: Bug
> Components: rpc, sasl, security
> Reporter: Duo Zhang
> Priority: Critical
> Fix For: 2.5.0, 3.0.0-alpha-4, 2.4.14
>
>
> Found this when implementing HBASE-27185. When running TestSecureIPC, if
> BlockingRpcClient is used, the tests will spend much more time comparing to
> NettyRpcClient.
> The problem is that, for the normal kerberos authentication, the last step is
> client send a reply to server, so after server receives the last token, it
> will not write anything back but expect client to send connection header.
> In HBASE-24579, for reading the error message, we added a readReply after the
> SaslClient indicates that the negotiation is completed. But as said above,
> for normal cases, we will not write anything back from server side, so the
> client will hang there and only throw an exception when timeout is reached,
> which is 20 seconds.
> This nearly makes the BlockingRpcClient unusable when sasl is enabled, as it
> will hang 20 seconds when connecting...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
