hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HBASE-15866) Split hbase.rpc.timeout into *.read.timeout and *.write.timeout
Date Thu, 19 May 2016 19:23:12 GMT
Andrew Purtell created HBASE-15866:
--------------------------------------

             Summary: Split hbase.rpc.timeout into *.read.timeout and *.write.timeout
                 Key: HBASE-15866
                 URL: https://issues.apache.org/jira/browse/HBASE-15866
             Project: HBase
          Issue Type: Bug
            Reporter: Andrew Purtell
             Fix For: 2.0.0


We have a single tunable for the RPC timeout interval - hbase.rpc.timeout. This is fine for
the general case but there are use cases where it would be advantageous to set two separate
timeouts for reads (gets, scans, perhaps with significant server side filtering - although
the new scanner heartbeat feature mitigates where available) and mutations (fail fast under
tight SLA, resubmit or take mitigating action). 

I propose we refer to a configuration setting "hbase.rpc.read.timeout" when handling read
operations and "hbase.rpc.write.timeout" when handling write operations. If those values are
not set in the configuration, fall back to the value of "hbase.rpc.timeout" or its default.


So for example in HTable instead of one global timeout for each RPC (rpcTimeout), there would
be a readRpcTimeout and writeRpcTimeout also set up in HTable#finishSetup. Then wherever we
set up RPC with RpcRetryingCallerFactory#newCaller(int rpcTimeout) we pass in the read or
write timeout depending on what the op is.

In general I don't like the idea of adding configuration parameters to our already heavyweight
set, but I think the inability to control timeouts separately for reads and writes is an operational
deficit.

See also PHOENIX-2916.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message