[
https://issues.apache.org/jira/browse/HBASE-27204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17570213#comment-17570213
]
Andrew Kyle Purtell commented on HBASE-27204:
---------------------------------------------
[PR#4642|https://github.com/apache/hbase/pull/4642]
When Kerberos authentication succeeds, on the server side, after receiving the
final SASL token from the client, we simply wait for the client to continue by
sending the connection header. After HBASE-24579, on the client side, an
additional `readStatus()` was added, which mistakenly assumes that after
negotiation has completed a status code will be sent. However when
authentication has succeeded the server will not send one. As a result the
client will hang and only throw an exception when the configured read timeout
is reached, which is 20 seconds by default.
We cannot unilaterally send the expected additional status code from the server
side because older clients will not expect it. The first call will fail because
the client finds unexpected bytes in the stream ahead of the call response.
Fabricating a call response
also does not seem a viable strategy for backwards compatibility.
The HBASE-24579 change needs to be reconsidered given the difficult backwards
compatibility challenges here.
> 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
> Assignee: Andrew Kyle Purtell
> 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)
