Major Description
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.
Attachments
Attachments
Issue Links
- is related to
-
PHOENIX-2916 Need a client-side level property to control write timeout
-
- Reopened
-
- links to
