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)
