[
https://issues.apache.org/jira/browse/HBASE-10606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911936#comment-13911936
]
Nick Dimiduk commented on HBASE-10606:
--------------------------------------
bq. Can't we just set it on construction and then be done w/ it rather than
provide exotic options?
+1 on doing away with setters for state like this.
{noformat}
- try {
- scanner.close();
- } catch (Throwable t) {
- LOG.debug("Got exception in closing the result scanner", t);
- }
+ scanner.close();
{noformat}
This is a little scary to me. This swallowed exception will now burp up in all
kinds of places (AssignmentManager, Handlers, &c), right?
{noformat}
- public MultiResponse callWithoutRetries(
RetryingCallable<MultiResponse> callable)
+ public MultiResponse
callWithoutRetries(RetryingCallable<MultiResponse> callable, int cto)
{noformat}
What is "cto"? "callTimeOut"?
nit, ws:
{noformat}
+ this.operationTimeout =
conf.getInt(HConstants.HBASE_CLIENT_OPERATION_TIMEOUT,
{noformat}
> Bad timeout in RpcRetryingCaller#callWithRetries w/o parameters
> ---------------------------------------------------------------
>
> Key: HBASE-10606
> URL: https://issues.apache.org/jira/browse/HBASE-10606
> Project: HBase
> Issue Type: Bug
> Components: Client
> Affects Versions: 0.99.0
> Reporter: Nicolas Liochon
> Assignee: Nicolas Liochon
> Fix For: 0.99.0
>
> Attachments: 10606.v1.patch, 10606.v2.patch
>
>
> When we call this method w/o parameters, we don't take into account the
> configuration, but use the hardcoded default (Integer.MAX).
> If someone was relying on having an infinite timeout whatever the setting,
> fixing this bug will cause him a surprise. But there is no magic...
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
