lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <rcm...@gmail.com>
Subject Re: LuceneTestCase.threadCleanup incorrectly reports left running threads
Date Sat, 25 Dec 2010 02:54:33 GMT
On Thu, Dec 23, 2010 at 2:09 AM, Shai Erera <serera@gmail.com> wrote:
> I don't know where this Timer is created, but I'll dig more.
>
> At any rate, I think your patch is good, and perhaps we should add the
> stacktrace print as well, to help with the debugging?
>
> Shai

OK, i'll commit the patch to rid of false positives (threads created
before our tests even start).

But I'm not sure about the stacktrace, it doesn't seem to be useful?

For example I was trying to debug why we create so many rogue threads
on Mac OS X, and it looks like:
    [junit] WARNING: test method: 'testDemo' left thread running:
Thread[Poller SunPKCS11-Darwin,1,main]
    [junit] [java.lang.Thread.sleep(Native Method),
sun.security.pkcs11.SunPKCS11$TokenPoller.run(SunPKCS11.java:692),
java.lang.Thread.run(Thread.java:680)]

This doesn't provide any hint that the real reason this thread is
started is FSDirectory's use of digester for getLockID().

I don't think we should use the java crypto API the way we do in
FSDirectory. Apparently whether or not it has an algorithm like MD5
depends on the java implementation (its not guaranteed), so I think we
should just include MD5Digest from bouncycastle or something like that
to avoid this.

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


Mime
View raw message