Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 13 Feb 2014 02:52:26 +0000 (UTC)
From: "Enis Soztutar (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12694305.1392053833831.34747.1392259946664@arcas>
In-Reply-To: <JIRA.12694305.1392053833831@arcas>
References: <JIRA.12694305.1392053833831@arcas>
Subject: [jira] [Commented] (HBASE-10490) Simplify RpcClient code
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Enis Soztutar commented on HBASE-10490:
---------------------------------------

It looks ok to me, but I am far from being an expert on the rpc / client side. Is there any reason why we are using negative call id's: 
{code}
this.id = callIdCnt.getAndDecrement();
{code} 


> Simplify RpcClient code
> -----------------------
>
>                 Key: HBASE-10490
>                 URL: https://issues.apache.org/jira/browse/HBASE-10490
>             Project: HBase
>          Issue Type: Bug
>          Components: Client
>    Affects Versions: 0.99.0
>            Reporter: Nicolas Liochon
>            Assignee: Nicolas Liochon
>             Fix For: 0.99.0
>
>         Attachments: 10490.v1.patch, 10490.v2.patch, 10490.v3.patch
>
>
> The code is complex. Here is a set of proposed changes, for trunk:
> 1) remove PingInputStream. if rpcTimeout > 0 it just rethrows the exception. I expect that we always have a rpcTimeout. So we can remove the code.
> 2) remove the sendPing: instead, just close the connection if it's not used for a while, instead of trying to ping the server.
> 3) remove maxIddle time: to avoid the confusion if someone has overwritten the conf.
> 4) remove shouldCloseConnection: it was more or less synchronized with closeException. Having a single variable instead of two avoids the synchro
> 5) remove lastActivity: instead of trying to have an exact timeout, just kill the connection after some time. lastActivity could be set to wrong values if the server was slow to answer.
> 6) hopefully, a better management of the exception; we don't use the close exception of someone else as an input for another one.  Same goes for interruption.
> I may have something wrong in the code. I will review it myself again. Feedback welcome, especially on the ping removal: I hope I got all the use cases. 


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)