Return-Path: X-Original-To: apmail-curator-dev-archive@minotaur.apache.org Delivered-To: apmail-curator-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9E815173D3 for ; Tue, 1 Sep 2015 03:04:47 +0000 (UTC) Received: (qmail 58214 invoked by uid 500); 1 Sep 2015 03:04:47 -0000 Delivered-To: apmail-curator-dev-archive@curator.apache.org Received: (qmail 58168 invoked by uid 500); 1 Sep 2015 03:04:47 -0000 Mailing-List: contact dev-help@curator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@curator.apache.org Delivered-To: mailing list dev@curator.apache.org Received: (qmail 58154 invoked by uid 99); 1 Sep 2015 03:04:47 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Sep 2015 03:04:47 +0000 Date: Tue, 1 Sep 2015 03:04:47 +0000 (UTC) From: "Martin Serrano (JIRA)" To: dev@curator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (CURATOR-257) Thread.sleep in TestingZooKeeperMain.blockUntilStarted is costly for unit tests MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CURATOR-257?page=3Dcom.atlassi= an.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Serrano updated CURATOR-257: ----------------------------------- Description:=20 The {{TestingZooKeeperMain.blockUntilStarted()}} contains a {{Thread.sleep(= 1000)}} call. In a large battery of unit level tests (which are otherwise = quick and depend on curator service discovery) this time adds up. Recent communication from JZ regarding the code: {quote} As I recall, it takes some time for the server to start up and this was a h= ack to make sure it=E2=80=99s ready. However, I no longer remember the det= ails. Do tests work with the timeout removed? {quote} We are in the midst of running our battery of tests to see if removal of th= is sleep call causes any issues. Our set of tests starts and stops the te= sting server a few hundred times within the same process, so I think it wil= l show any such issues within a few runs. If no issues appear (and the cur= ator tests pass of course) I will post a pull request. =20 A sleep of this sort is unreliable to ensure startup anyway. While it may = be very unlikely for the server not to be up after 1 second, I've found wit= h similar approaches that these types of solutions will still fail once it = a while, leading to odd and hard to reproduce test failures. was: The {{TestingZooKeeperMain.blockUntilStarted()}} contains a {{Thread.sleep(= 1000)}} call. In a large battery of unit level tests (which are otherwise = quick and depend on curator service discovery) this time adds up. Recent communication from JZ regarding the code: {quote} As I recall, it takes some time for the server to start up and this was a h= ack to make sure it=E2=80=99s ready. However, I no longer remember the det= ails. Do tests work with the timeout removed? {quote} We are in the midst of running our battery of tests to see if removal of th= is sleep call causes any issues. Our set of tests starts and stops the te= sting server a few hundred times within the same thread, so I think it will= show any such issues within a few runs. If no issues appear (and the cura= tor tests pass of course) I will post a pull request. =20 A sleep of this sort is unreliable to ensure startup anyway. While it may = be very unlikely for the server not to be up after 1 second, I've found wit= h similar approaches that these types of solutions will still fail once it = a while, leading to odd and hard to reproduce test failures. > Thread.sleep in TestingZooKeeperMain.blockUntilStarted is costly for unit= tests > -------------------------------------------------------------------------= ------ > > Key: CURATOR-257 > URL: https://issues.apache.org/jira/browse/CURATOR-257 > Project: Apache Curator > Issue Type: Improvement > Components: Tests > Reporter: Martin Serrano > Priority: Minor > > The {{TestingZooKeeperMain.blockUntilStarted()}} contains a {{Thread.slee= p(1000)}} call. In a large battery of unit level tests (which are otherwis= e quick and depend on curator service discovery) this time adds up. > Recent communication from JZ regarding the code: > {quote} > As I recall, it takes some time for the server to start up and this was a= hack to make sure it=E2=80=99s ready. However, I no longer remember the d= etails. Do tests work with the timeout removed? > {quote} > We are in the midst of running our battery of tests to see if removal of = this sleep call causes any issues. Our set of tests starts and stops the = testing server a few hundred times within the same process, so I think it w= ill show any such issues within a few runs. If no issues appear (and the c= urator tests pass of course) I will post a pull request. =20 > A sleep of this sort is unreliable to ensure startup anyway. While it ma= y be very unlikely for the server not to be up after 1 second, I've found w= ith similar approaches that these types of solutions will still fail once i= t a while, leading to odd and hard to reproduce test failures. -- This message was sent by Atlassian JIRA (v6.3.4#6332)