Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7947E10D00 for ; Thu, 27 Feb 2014 12:48:23 +0000 (UTC) Received: (qmail 53427 invoked by uid 500); 27 Feb 2014 12:48:22 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 53394 invoked by uid 500); 27 Feb 2014 12:48:22 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 53181 invoked by uid 99); 27 Feb 2014 12:48:21 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Feb 2014 12:48:21 +0000 Date: Thu, 27 Feb 2014 12:48:21 +0000 (UTC) From: "Liang Xie (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (HBASE-10088) SecureClient will hang when access secure-disabled cluster MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-10088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liang Xie updated HBASE-10088: ------------------------------ Assignee: cuijianwei > 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 (v6.1.5#6160)