Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 6 Oct 2012 15:11:03 +0000 (UTC)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <236393697.5140.1349536263418.JavaMail.jiratomcat@arcas>
In-Reply-To: <1859266452.155178.1349197627909.JavaMail.jiratomcat@arcas>
Subject: [jira] [Commented] (HBASE-6920) On timeout connecting to master,
 client can get stuck and never make progress
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Lars Hofhansl commented on HBASE-6920:
--------------------------------------

Now TestClientTimeouts always fails in the Security build.

So, here's what I am going to do: I'll revert the test part of this change, then we can file a new ticket for the 0.96 investigation and the testing part.
                
> On timeout connecting to master, client can get stuck and never make progress
> -----------------------------------------------------------------------------
>
>                 Key: HBASE-6920
>                 URL: https://issues.apache.org/jira/browse/HBASE-6920
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.94.2
>            Reporter: Gregory Chanan
>            Assignee: Gregory Chanan
>            Priority: Critical
>             Fix For: 0.94.2
>
>         Attachments: 6920-addendum.txt, HBASE-6920.patch, HBASE-6920-v2.patch
>
>
> HBASE-5058 appears to have introduced an issue where a timeout in HConnection.getMaster() can cause the client to never be able to connect to the master.  So, for example, an HBaseAdmin object can never successfully be initialized.
> The issue is here:
> {code}
> if (tryMaster.isMasterRunning()) {
>   this.master = tryMaster;
>   this.masterLock.notifyAll();
>   break;
> }
> {code}
> If isMasterRunning times out, it throws an UndeclaredThrowableException, which is already not ideal, because it can be returned to the application.
>  But if the first call to getMaster succeeds, it will set masterChecked = true, which makes us never try to reconnect; that is, we will set this.master = null and just throw MasterNotRunningExceptions, without even trying to connect.
> I tried out a 94 client (actually a 92 client with some 94 patches) on a cluster with some network issues, and it would constantly get stuck as described above.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira