Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of dawid.weiss@gmail.com
 designates 209.85.210.176 as permitted sender)
Received-SPF: pass (google.com: domain of dawid.weiss@gmail.com designates
 10.50.207.65 as permitted sender) client-ip=10.50.207.65;
MIME-Version: 1.0
From: Dawid Weiss <dawid.weiss@gmail.com>
Date: Thu, 1 Mar 2012 11:24:15 +0100
Message-ID: 
 <CAM21Rt8_9eU_QsX9WH369SAf7zQCENO5heFZYsOTXMwDrmrTEw@mail.gmail.com>
Subject: ThreadPool threads leaking to suite scope.
To: dev@lucene.apache.org
Content-Type: text/plain; charset=UTF-8

Question -- TestPhraseQuery has a static @BeforeClass initialized
searcher. With a certain seed this searcher is now initialized with an
underlying ThreadPool but the threadpool's threads (even though it's a
fixed TP) don't get preallocated until the first job is submitted
(executor's contract).

What this causes is a thread leak - like behavior because from the
test's viewpoint the number of threads on the entry and exit don't
match.  I see two options here:

1) initialize threads eagerly; use ThreadPoolExecutor and call
prestartAllCoreThreads. this could be applied to LTC on the trunk.

2) RandomizedRunner allows tests to leak threads to the suite scope
(which then must add up to zero on exit). I temporarily did this on rr
branch:
@ThreadLeaks(linger = 1000, leakedThreadsBelongToSuite = true)

Lingering is required because thread pools do not wait for their
threads to actually die (all they do is they leave them to die, but
not join). This could also be fixed on LTC level by joining all
threads started by that custom thread factory.

Dawid

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