[ https://issues.apache.org/jira/browse/HBASE-17449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16353961#comment-16353961 ]
Peter Somogyi commented on HBASE-17449: --------------------------------------- I started to look into how can we test the different timeouts. My idea is to start up a minicluster, execute different types of requests (mutations, scans, admin operations, etc.) while we add some delay on the server side. What I have already noticed is that even to start up a cluster "hbase.client.operation.timeout" is in use. When I put it to 1ms (I know it is not something you would use in real life scenario) the cluster did not come up. It caused endless retries even though I saw DoNotRetryIOException in the log. What do you think about this approach? > Add explicit document on different timeout settings > --------------------------------------------------- > > Key: HBASE-17449 > URL: https://issues.apache.org/jira/browse/HBASE-17449 > Project: HBase > Issue Type: Improvement > Components: documentation > Reporter: Yu Li > Assignee: Yu Li > Priority: Critical > Fix For: 2.0.0-beta-2 > > > Currently we have more than one timeout settings, mainly includes: > * hbase.rpc.timeout > * hbase.client.operation.timeout > * hbase.client.scanner.timeout.period > And in latest branch-1 or master branch code, we will have two other > properties: > * hbase.rpc.read.timeout > * hbase.rpc.write.timeout > However, in current refguid we don't have explicit instruction on the > difference of these timeout settings (there're explanations for each > property, but no instruction on when to use which) > In my understanding, for RPC layer timeout, or say each rpc call: > * Scan (openScanner/next): controlled by hbase.client.scanner.timeout.period > * Other operations: > 1. For released versions: controlled by hbase.rpc.timeout > 2. For 1.4+ versions: read operation controlled by hbase.rpc.read.timeout, > write operation controlled by hbase.rpc.write.timeout, or hbase.rpc.timeout > if the previous two are not set. > And hbase.client.operation.timeout is a higher-level control counting retry > in, or say the overall control for one user call. > After this JIRA, I hope when users ask questions like "What settings I should > use if I don't want to wait for more than 1 second for a single > put/get/scan.next call", we could give a neat answer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)