[ 
https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vivek Koppuru updated HBASE-15866:
----------------------------------
    Attachment: read-write-rpc-timeouts.patch

This includes all the changes necessary to split "hbase.rpc.timeout" into 
"hbase.rpc.read.timeout" and "hbase.rpc.write.timeout".

> 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
>            Assignee: Vivek Koppuru
>             Fix For: 2.0.0
>
>         Attachments: read-write-rpc-timeouts.patch
>
>
> 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)

Reply via email to