hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Devaraj Das (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10490) Simplify RpcClient code
Date Tue, 11 Feb 2014 08:00:23 GMT

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

Devaraj Das commented on HBASE-10490:
-------------------------------------

Nice cleanup, but hopefully we can make sure the changes doesn't break any assumption in the
RPC layer. The 'ping' removal stood out while I was doing a review. Am wondering if the server
side works well with this change.. i mean could this happen
(1) client sends an RPC
(2) server got to it but the request is taking a long time to process
(3) meanwhile the server sees the connection as idle and closes it
(since no ping came)
The other thing is if the client's intended socket timeout is 0 (infinite timeout), wondering
if the ping is relevant then to prevent server from closing the connection on incomplete/not-yet-responded
RPCs.

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

Mime
View raw message