Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of dawid.weiss@gmail.com
 designates 209.85.160.176 as permitted sender)
MIME-Version: 1.0
Sender: dawid.weiss@gmail.com
In-Reply-To: 
 <CAL8PwkYPt6Lf7U78XHDd9njqmwJkTtfpfBit5sde8=Ust4ExiQ@mail.gmail.com>
References: 
 <CAOdYfZXYznsy=t6EsgGBhg+4P593beEUzu-6qXeOqNGRMdmrhg@mail.gmail.com>
 <CAL8PwkaeTx7y3i5v0gDCpxEUhLOdoYPk4ft1Zhb9iR+jwgbxdQ@mail.gmail.com>
 <CAM21Rt_JdEsbhkvu_c76Wy-JT3nauYMtP=PCWKyom9fvPVquGQ@mail.gmail.com>
 <alpine.DEB.2.00.1204301516000.6870@bester>
 <CAM21Rt8fE5U32KEZ9oEA=N+0T2yd6BMmwNFmJBfefbAXC4Z7Hg@mail.gmail.com>
 <CAL8PwkYPt6Lf7U78XHDd9njqmwJkTtfpfBit5sde8=Ust4ExiQ@mail.gmail.com>
From: Dawid Weiss <dawid.weiss@cs.put.poznan.pl>
Date: Wed, 2 May 2012 11:05:14 +0200
Message-ID: 
 <CAM21Rt_81YzTXg5GuhUZQ_==F-dgFJhgO5oDS3=r6CszPxriRA@mail.gmail.com>
Subject: Re: hudson hung
To: dev@lucene.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> Hmm, as a test, I tried adding @Timeout(millis=3D100000) to
> LuceneTestCase, ie 100 seconds, which I think should not trigger on
> any core tests today.
>
> That should then apply to all subclasses of LuceneTestCase right? =C2=A0I=
e
> all tests will be aborted after 100 seconds...

Yes, it should abort each test after 100 seconds (or not if it
completes earlier).

> But, something is wrong: I get lots of quick (ie much less than 100
> seconds) failures like this:
>
> =C2=A0 [junit4] Suite: org.apache.lucene.util.TestRamUsageEstimatorOnWild=
Animals
> =C2=A0 [junit4] ERROR =C2=A0 0.00s J2 | TestRamUsageEstimatorOnWildAnimal=
s (suite)
> =C2=A0 [junit4] =C2=A0 =C2=A0> Throwable #1: java.lang.RuntimeException: =
Interrupted
> while waiting for worker? Weird.

I'm not sure what's wrong and I'm not able to tell you right now
(vacation...). I will look into this once I come back.

The problem of "stopping" a running test is not trivial because there
are no easy ways of telling which threads have been started from a
test, which threads should outlive the test (as in a threadpool
initialized from @BeforeClass but used from within a test -- the pool
threads should outlive it)... finally there are cases when a thread
just won't make it possible to be killed by an external threads (see
test cases in randomizedtesting -- look for zombie tests if you're
curious).

There are many sneaky scenarios. The timeout on jenkins is also not
trivial I think. Uwe was reporting that stopping a build on jenkins
leaves forked jvms running in the background. I looked into jenkins
source code to see how they're killing those running processes... it's
really hairy -- os-dependent and doing scans of /proc... brr...
Apparently also not an easy thing to do.

I'll upgrade junit4 and randomizedtesting to version 1.4.0 which
should fix a few problems related to event passing but I'll have to
postpone timeouts until I'm back at work full time.

Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org