On Sun, Dec 26, 2010 at 5:17 AM, Uwe Schindler wrote:
> About MD5: At least for Lucene 3.x we must stay with MD5, as changing the
> hash algorithm would change the lock file name, so an index locked with 3.0
> would have a different lock file than an index locked with 3.x (for external
> lock dire
On Sat, Dec 25, 2010 at 9:03 AM, Shai Erera wrote:
> As for the other threads that are left running, I couldn't track down
> yet the warning from the benchmark tests,
I havent looked yet, but i think benchmark depends on/uses the demo
html parser (what a strange dependency)... and the demo html
n strange
> sophisticated backwards assumptions, just my opinion).
>
>
>
> Uwe
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Shai Erera
Sunday, December 26, 2010 7:43 AM
To: dev@lucene.apache.org
Subject: Re: LuceneTestCase.threadCleanup incorrectly reports left running
threads
Thanks for the explanation Uwe. I got confused with that and the process
name we add to the temp lock file.
About what you say, we have a scenari
igest
> code anymore.
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Shai Erera [mailto:ser...@gmail.com]
> > Sent: Saturday, December
t; Subject: Re: LuceneTestCase.threadCleanup incorrectly reports left running
> threads
>
> Actually, the MD5 thingy is an attempt to generate a unique temp lock ID,
> IIRC. so this piece of code can disappear entirely now that the tests
> concurrency is better.
>
> As for the o
nauer [mailto:simon.willna...@googlemail.com]
Sent: Saturday, December 25, 2010 6:30 PM
To: dev@lucene.apache.org
Subject: Re: LuceneTestCase.threadCleanup incorrectly reports left running
threads
On Sat, Dec 25, 2010 at 3:05 PM, Earwin Burrfoot wrote:
> I think we can take some public algos like
On Sat, Dec 25, 2010 at 3:05 PM, Earwin Burrfoot wrote:
> I think we can take some public algos like lookup3 / murmurhash2/3,
> and stuff them into Lucene utils.
>
> Java implementations (very simple and fast ones) exist for both of these.
>
> I.e. lookup3 done by Yonik (http://people.apache.org/~
Jaja. Dont want to discuss about that. :'(
Merry Xmas! :)
"Robert Muir" schrieb:
>On Sat, Dec 25, 2010 at 9:24 AM, Uwe Schindler wrote:
>>
>http://download.oracle.com/javase/1.4.2/docs/guide/security/CryptoSpec.html
>>
>> Under "architecture", same document exists for later jvms. This is
>t
On Sat, Dec 25, 2010 at 9:24 AM, Uwe Schindler wrote:
> http://download.oracle.com/javase/1.4.2/docs/guide/security/CryptoSpec.html
>
> Under "architecture", same document exists for later jvms. This is the same
> type of document that e.g. lists default charsets.
>
I don't see anywhere in this
http://download.oracle.com/javase/1.4.2/docs/guide/security/CryptoSpec.html
Under "architecture", same document exists for later jvms. This is the same
type of document that e.g. lists default charsets.
Uwe
"Robert Muir" schrieb:
>On Sat, Dec 25, 2010 at 4:04 AM, Uwe Schindler wrote:
>> Md
I think we can take some public algos like lookup3 / murmurhash2/3,
and stuff them into Lucene utils.
Java implementations (very simple and fast ones) exist for both of these.
I.e. lookup3 done by Yonik (http://people.apache.org/~yonik/code/hash/),
murmurhash2 - by Andrzej Bialecki (
http://www.g
Actually, the MD5 thingy is an attempt to generate a unique temp lock
ID, IIRC. so this piece of code can disappear entirely now that the
tests concurrency is better.
As for the other threads that are left running, I couldn't track down
yet the warning from the benchmark tests, but I'd love to get
On Sat, Dec 25, 2010 at 4:04 AM, Uwe Schindler wrote:
> Md5 is guaranteed to be there (like utf8 as charset). This is documented in
> crypto Api, which algorithms are available for digest.
>
where is this documented? its not in the javadocs.
anyway, we shouldn't be doing this:
* this algorithm
Md5 is guaranteed to be there (like utf8 as charset). This is documented in
crypto Api, which algorithms are available for digest.
Uwe
"Robert Muir" schrieb:
>On Thu, Dec 23, 2010 at 2:09 AM, Shai Erera wrote:
>> I don't know where this Timer is created, but I'll dig more.
>>
>> At any rate
On Thu, Dec 23, 2010 at 2:09 AM, Shai Erera 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 p
I ran the test from both eclipse and Ant, and got similar warnings.
With your patch most of the 'false alarms' do not show up again, but I still
see a strange failure. I add this to after the System.err.print("left thread
running"): System.err.println(Arrays.toString(t.getStackTrace())); -- it
pri
here is a (imperfect) patch for eclipse, can you try this? any threads
running at this point are not our own.
Index: lucene/src/test/org/apache/lucene/util/LuceneTestCase.java
===
--- lucene/src/test/org/apache/lucene/util/LuceneTestC
On Wed, Dec 22, 2010 at 2:14 PM, Shai Erera wrote:
> Hi
>
> I noticed that some tests report threads are left running, even when those
> tests never create and start a Thread. Digging deeper I found out that the
> tests report "Signal Dispatcher" and "Attach handler" as two threads that
> are left
Hi
I noticed that some tests report threads are left running, even when those
tests never create and start a Thread. Digging deeper I found out that the
tests report "Signal Dispatcher" and "Attach handler" as two threads that
are left running. If I run the test from eclipse, then a "ReaderThread"
20 matches
Mail list logo
