[
https://issues.apache.org/jira/browse/HBASE-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-3114:
-------------------------
Attachment: 3114-v2.txt
This version of the patch seems to pass on multiple tries on two different OSs.
Will commit. Here is commit message:
{code}
M src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java
Add a passedZkCluster flag. If we didn't start the zk cluster,
don't shut it down on way out.
M src/test/java/org/apache/hadoop/hbase/TestHBaseTestingUtility.java
Add a test that starts up three clusters in a vm all sharing single
zk, each to its own chroot location. Add to tables in each and
very the add by doing same as the old TestMultiClusters used)
M src/test/java/org/apache/hadoop/hbase/replication/TestReplication.java
Reenable shutdown of started clusters. Hopefully this clears
the leaking of zk ensembles up on hudson.
M src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWatcher.java
Testing, it looks like legitimately the callback for session connected
can be invoked before construction of zookeeperwatcher finishes. In
particular the zookeeper data member can be null. Hang around for a
second of so before throwing an exception (Make the exception
indicate the particular zkw by adding to the error message stack
trace made at zkw construction -- helps with debugging this stuff)
{code}
Will commit to see if this cures the leaking ensembles up on hudson.
Here is where we are currently at in that regard:
{code}
2010-10-15 23:40:37,416 INFO [main] zookeeper.MiniZooKeeperCluster(111):
Failed binding ZK Server to client port: 21818
2010-10-15 23:40:37,418 INFO [main] zookeeper.MiniZooKeeperCluster(111):
Failed binding ZK Server to client port: 21819
2010-10-15 23:40:37,419 INFO [main] zookeeper.MiniZooKeeperCluster(111):
Failed binding ZK Server to client port: 21820
2010-10-15 23:40:37,419 INFO [main] zookeeper.MiniZooKeeperCluster(111):
Failed binding ZK Server to client port: 21821
2010-10-15 23:40:37,480 INFO [main] zookeeper.MiniZooKeeperCluster(125):
Started MiniZK Server on client port: 21822
{code}
This patch will not fix the sporadic fail of TestReplication. J-D is on that.
{code}
> Test up on hudson are leaking zookeeper ensembles
> -------------------------------------------------
>
> Key: HBASE-3114
> URL: https://issues.apache.org/jira/browse/HBASE-3114
> Project: HBase
> Issue Type: Bug
> Components: test
> Reporter: stack
> Assignee: stack
> Fix For: 0.90.0
>
> Attachments: 3114-v2.txt, 3114.txt
>
>
> Here is from a recent run up on Hudson:
> {code}
> 2010-10-14 23:31:56,482 INFO [main] zookeeper.MiniZooKeeperCluster(111):
> Failed binding ZK Server to client port: 21818
> 2010-10-14 23:31:56,483 INFO [main] zookeeper.MiniZooKeeperCluster(111):
> Failed binding ZK Server to client port: 21819
> 2010-10-14 23:31:56,483 INFO [main] zookeeper.MiniZooKeeperCluster(111):
> Failed binding ZK Server to client port: 21820
> 2010-10-14 23:31:56,522 INFO [main] zookeeper.MiniZooKeeperCluster(125):
> Started MiniZK Server on client port: 21821
> {code}
> See how we start trying to bind to 21818 but we don't get a free port till we
> get to 21821?
> Some test or tests is not cleaning up after itself leaving a running zk
> cluster or two about.
> TestReplication looks to be suspect. Here is its @AfterClass method:
> {code}
> /**
> * @throws java.lang.Exception
> */
> @AfterClass
> public static void tearDownAfterClass() throws Exception {
> /* REENABLE
> utility2.shutdownMiniCluster();
> utility1.shutdownMiniCluster();
> */
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
