[ https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408192#comment-15408192 ]
Andrew Purtell commented on HBASE-15866: ---------------------------------------- [~vivek.kopp...@gmail.com] when I apply this patch to latest master, I have to fix up HConnectionTestingUtility to fix a compilation problem. When running tests, TestHCM#testRpcTimeout fails with this patch applied but not otherwise. I'm attaching a patch that includes the HConnectionTestingUtility change. Let me look at the test failure, maybe it's an easy fix. > 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 > Affects Versions: 2.0.0 > Reporter: Andrew Purtell > Assignee: Vivek Koppuru > Labels: newbie, patch > 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)