hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10088) SecureClient will hang when access secure-disabled cluster
Date Thu, 27 Feb 2014 12:54:19 GMT

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

Hadoop QA commented on HBASE-10088:

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  against trunk revision .
  ATTACHMENT ID: 12617318

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:red}-1 tests included{color}.  The patch doesn't appear to include any new or modified
                        Please justify why no new tests are needed for this patch.
                        Also please list what manual steps were performed to verify this patch.

    {color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/8834//console

This message is automatically generated.

> SecureClient will hang when access secure-disabled cluster
> ----------------------------------------------------------
>                 Key: HBASE-10088
>                 URL: https://issues.apache.org/jira/browse/HBASE-10088
>             Project: HBase
>          Issue Type: Improvement
>          Components: Client, security
>    Affects Versions: 0.94.14
>            Reporter: cuijianwei
>            Assignee: cuijianwei
>         Attachments: HBASE-10088-0.94-v1.patch, HBASE-10088-0.94-v2.patch, HBASE-10088-0.94-v2.patch
> When I misuse a secure hbase client to access a secure-disabled hbase server, I found
the client will hang. The reason is that client will firstly invoke rpc method "getProtocolVersion",
and the response from a secure-disabled server won't contain necessary fields processed by
SecureClient. SecureClient will process the response as follows : (from SecureClient.receiveResponse()):
> {code}
> if (state == Status.SUCCESS.state) {
>           Writable value = ReflectionUtils.newInstance(valueClass, conf);
>           value.readFields(in);                 // read value
>           if (LOG.isDebugEnabled()) {
>             LOG.debug("call #"+id+", response is:\n"+value.toString());
>           }
>           // it's possible that this call may have been cleaned up due to a RPC
>           // timeout, so check if it still exists before setting the value.
>           if (call != null) {
>             call.setValue(value);
>           }
>         } else if (state == Status.ERROR.state) {
>           if (call != null) {
>             call.setException(new RemoteException(WritableUtils.readString(in), WritableUtils
>                 .readString(in)));
>           }
>         } else if (state == Status.FATAL.state) {
>           RemoteException exception = new RemoteException(WritableUtils.readString(in),
>               WritableUtils.readString(in));
>           // the call will be removed from call map, we must set Exception here to notify
>           // the thread waited on the call
>           if (call != null) {
>             call.setException(exception);
>           }
>           // Close the connection
>           markClosed(exception);
>         }
>         calls.remove(id);
> {code}
> As the above code, SecureClient need to read 'state' field from response. If the response
is from a secure-disabled server, there will no 'state' field in response and SecureClient
will get an illegal 'state', then the call will be removed from cached calls without notifying
waiting thread. This will make the invoker waiting all the time. Although we should not use
secure client to access secure-disabled server, users might encounter this situation because
of misusing or error configuration. If the client will hang in this situation, users might
not know the error quickly. Maybe, it is better to report an error in this situation so that
users will know what happens quickly.

This message was sent by Atlassian JIRA

View raw message