[
https://issues.apache.org/jira/browse/HBASE-10490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13898396#comment-13898396
]
stack commented on HBASE-10490:
-------------------------------
bq. meanwhile the server sees the connection as idle and closes it
If server is taking > timeout to reply, the client will be gone anyways? If
request is taking tens of seconds, we should kill it? If this is expected, up
the socket timeout?
bq. we can remove the ping on the client without changing anything in the
server:
We could. I like purging ping altogether (unless I'm wrong above) since it
puts a particular shape on how we process the incoming requests (look for the
special -1 length indicator and short circuit if a ping) and would like this
cleaned up so easier putting in another request handling (e.g. async).
bq. But I agree that if no one uses rpcTimeout = 0, we could remove the ping
stuff.
Lets beat anyone who has their rpcTimeout to 0. Smile (That said, I have vague
recollection that rpcTimeout==0 was how we defaulted at one time so let me go
beat myself in the past)
> 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)
