[
https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vivek Koppuru updated HBASE-15866:
----------------------------------
Labels: newbie patch (was: )
Affects Version/s: 2.0.0
Status: Patch Available (was: In Progress)
I split the rpcTimeout in HTable.java into readRpcTimeout and writeRpcTimeout,
which can also go back to the rpcTimeout value that would be set if the user
did not configure those values. Then throughout HTable, whenever making an
rpcCallerFactory call, I would pass the appropriate read/write rpc timeout. I
also made a change to the AsyncProcess class constructor to allow for the use
of writeRpcTimeout, which then I made appropriate changes to
BufferedMutatorImpl.java, ConnectionImplementation.java,
HTableMultiplexer.java, and TestAsyncProcess.java to account for this parameter
change and passed in the appropriate rpc timeout. Finally, I made sure I
included constants in HConstants.java to retrieve the value of
"hbase.rpc.read.timeout" and "hbase.rpc.write.timeout" and to also allow for
fallback to "hbase.rpc.timeout" and the default rpc timeout if none of those
are set.
> 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)
