[ 
https://issues.apache.org/jira/browse/HBASE-27204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17568261#comment-17568261
 ] 

Andrew Kyle Purtell commented on HBASE-27204:
---------------------------------------------

Let me take this. I also need to think over the issues.

I am inclined to fall back to fixing this by reverting HBASE-24579, with a 
release note, if all else fails. This would fix the issue in 2.5 and up. Not 
sure about 2.4. Maybe it stays as a known issue. BlockingRpcClient is not the 
default, there is that. I realize this is unsatisfactory for those who have a 
custom client so am wondering if we can do concurrent async read (of the 
status) and write (of the connection header) at this point where we known SASL 
is complete and the join on those conditions to catch both cases and wait at 
the right time without causing a stall. Or perhaps simply write the header 
first and then read to see what is going on. Need to spend some time with the 
code, I think. 

> 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)

Reply via email to