[
https://issues.apache.org/jira/browse/HBASE-27204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17567457#comment-17567457
]
Duo Zhang commented on HBASE-27204:
-----------------------------------
{quote}
this unexpected behaviour may occur even with the netty client rpc
{quote}
You mean the unexpected hanging? Or we miss the sasl error response? I haven't
seen the former behavior, and if the PLAIN sasl behave like this, I think the
latter statement is correct, netty rpc client will also have the same problem.
So if this is the expected behavior, I mean the PLAIN sasl protocol can fail
after client has already completed, then we need to consider other approaches
to fix the problem.
And first, I think the server could just close the connection when the
authentication fails? So at least the client will know that there is something
wrong. This is the first thing we need to confirm.
I do not have a good enough idea on how to send back the error response to
client side after the client has already finished negotiation, as client will
expect normal rpc response now(or the connection header response if needed).
Send the error back as normal rpc response? But how to deal with the call id?
Client will just drop it since there is no actual rpc call yet?
Thanks.
> 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)
