Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 25 Feb 2014 19:14:20 +0000 (UTC)
From: "stack (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12697150.1393347412029.102679.1393355660078@arcas>
In-Reply-To: <JIRA.12697150.1393347412029@arcas>
References: <JIRA.12697150.1393347412029@arcas>
Subject: [jira] [Commented] (HBASE-10606) Bad timeout in
 RpcRetryingCaller#callWithRetries w/o parameters
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-10606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911905#comment-13911905 ] 

stack commented on HBASE-10606:
-------------------------------

We need this?

+  public void setOperationTimeout(int operationTimeout) {


Can't we just set it on construction and then be done w/ it rather than provide exotic options?

This goes away?  Not needed any more?  Not even as a noop?

-  private void beforeCall() {

Patch looks great.  +1.  If we are removing some infinite timeout, good; commit and lets live w/ the consequence.

> 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)