Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 16 Nov 2011 11:54:51 +0000 (UTC)
From: "nkeywal (Commented) (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <1970310924.34587.1321444491653.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1172788321.34288.1321433451709.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-4798) Sleeps and synchronisation
 improvements for tests
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

nkeywal commented on HBASE-4798:
--------------------------------

@commiters: for catalog.TestCatalogTrackerOnCluster.testBadOriginalRootLocation, the test is
{noformat}
    ServerName nonsense =
      new ServerName("example.org", 1234, System.currentTimeMillis());
    RootLocationEditor.setRootLocation(zookeeper, nonsense);
    // Bring back up the hbase cluster.  See if it can deal with nonsense root
    // location.
    UTIL.startMiniHBaseCluster(1, 1);
    UTIL.shutdownMiniCluster();
{noformat}

It appears that when the root location is invalid, the master cannot be initialized. The exception fails now because I modified the JVMClusterUtil#startup to make sure that the cluster is initialized when we leave the method (with a timeout avec 30s: that what's going on here). I prefer this, because it's a well known state (instead of sometimes initialized; sometimes not, depending on the sleeps that took place). It means that I would have to modify this test case to make it accept the exception. Are you ok?

I also look after the other errors.

                
> Sleeps and synchronisation improvements for tests
> -------------------------------------------------
>
>                 Key: HBASE-4798
>                 URL: https://issues.apache.org/jira/browse/HBASE-4798
>             Project: HBase
>          Issue Type: Improvement
>          Components: master, regionserver, test
>    Affects Versions: 0.94.0
>         Environment: all
>            Reporter: nkeywal
>            Assignee: nkeywal
>            Priority: Minor
>         Attachments: 4798_trunk_all.v2.patch
>
>
> Multiple small changes:
> @commiters: Removing some sleeps made visible a bug on JVMClusterUtil#HMaster#waitForServerOnline, so I had to add a synchro point. You may want to review this.
> JVMClusterUtil#HMaster#waitForServerOnline: removed, the condition was never met (test on "!c && !!c"). Added a new synchronization point.
> AssignementManager#waitForAssignment: add a timeout on the wait => not stuck if the notification is received before the wait.
> HMaster#loop: use a notification instead of a 1s sleep
> HRegionServer#waitForServerOnline: new method used by JVMClusterUtil#waitForServerOnline() to replace a 1s sleep by a notification
> HRegionServer#getMaster() 1s sleeps replaced by one 0,1s sleep and one 0,2s sleep
> HRegionServer#stop: use a notification on sleeper to lower shutdown by 0,5s
> ZooKeeperNodeTracker#start: replace a recursive call by a loop
> ZooKeeperNodeTracker#blockUntilAvailable: add a timeout on the wait => not stuck if the notification is received before the wait.
> HBaseTestingUtility#expireSession: use a timeout of 1s instead of 5s
> TestZooKeeper#testClientSessionExpired: use a timeout of 1s instead of 5s, with the change on HBaseTestingUtility we are 60s faster
> TestRegionRebalancing#waitForAllRegionsAssigned: use a sleep of 0,2s instead of 1s
> TestRestartCluster#testClusterRestart: send all the table creation together, then check creation, should be faster
> TestHLog: shutdown the whole cluster instead of DFS only (more standard) 
> JVMClusterUtil#startup: lower the sleep from 1s to 0,1s
> HConnectionManager#close: Zookeeper name in debug message from HConnectionManager after connection close was always null because it was set to null in the delete.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira