RE: SorterTemplate.quickSort causes StackOverflowError

> Thanks for confirming, Javier! :) > > Uwe, I assume you are referring to this line 528 in MemoryIndex? > > 528 if (size > 1) ArrayUtil.quickSort(entries, termComparator); > > And this funky Comparator from MemoryIndex: > > 208 private static final Comparator termComparator = new

Re: SorterTemplate.quickSort causes StackOverflowError

Thanks for confirming, Javier! :) Uwe, I assume you are referring to this line 528 in MemoryIndex? 528 if (size > 1) ArrayUtil.quickSort(entries, termComparator); And this funky Comparator from MemoryIndex: 208 private static final Comparator termComparator = new Comparator() {

RE: SorterTemplate.quickSort causes StackOverflowError

Hi Otis, Can you reproduce this somehow and send test code? I could look into it. I don't expect the error in the quicksort algorithm itself as this one is used e.g. BytesRefHash / TermsHash, if there is a bug we would have seen it long time ago. I have not seen this before, but I suspect a probl

Re: SorterTemplate.quickSort causes StackOverflowError

Hi Otis, I have exactly the same scenario, also on 3.1, the only difference is I have less queries, like 20 or 30. Yesterday this code processed over 1 million incoming docs (in a synthetic test), and did not get any error... Not very helpful maybe but just so you get some other feedback. javie

SorterTemplate.quickSort causes StackOverflowError

Hi, I'm looking at some code that uses MemoryIndex (Lucene 3.1) and that's exhibiting a strange behaviour - it slows down over time. The MemoryIndex contains 1 doc, of course, and executes a set of a few thousand queries against it. The set of queries does not change - the same set of queries

Re: lucene 3.1 contrib packages source code download

Can you check here > http://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/contrib/ Isn't this what you are looking for? On Thu, Apr 28, 2011 at 11:26 PM, Erick Erickson wrote: > Are you sure you need to? They may simply hav

Re: lucene 3.1 contrib packages source code download

Are you sure you need to? They may simply have moved. Which ones are you using? If you tell us maybe we can suggest where to find them. Best Erick On Thu, Apr 28, 2011 at 9:14 AM, Tanuj Jain wrote: > Hi, > Can anyone please tell where I could download *packages > org.apache.lucene.analysis.* *so

RE: Immutable OpenBitSet?

That was exactly what I demonstrated in another mail on this thread: final OpenBitSet mybits = new OpenBitSet(size) {{ fastSet(1); fastSet(2);... }}; Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message-

RE: Immutable OpenBitSet?

I agree that Trejkaz's example is correct and consistent with both the JLS spec and "Java Concurrency in Practice", by Goetz. Without synchronization, the final keyword is necessary to ensure all values set on a long[] in a constructor are seen by other threads in the state they were when the

RE: Immutable OpenBitSet?

The missing safe publish of the reference to the object is the problem here. Once you have published "f" safely between writer and reader, all contents and references to other objects inside the FinalFieldExample are visible. The final modifier on this only assures in the case of no safe publish

RE: Immutable OpenBitSet?

This is all not a problem, if the reference to the newly created object is passed e.g. into a synchronized cache (like it is done in CachingWrapperFilter). When entering the synchronized method that adds the reference to the object to the cache (in the filter case it’s the OpenBitSet created sh

Re: lucene 3.1 contrib packages source code download

Hi Tanuj! If you are familiar with subversion this is the place http://wiki.apache.org/lucene-java/SourceRepository Regards, Yiannis On Thu, Apr 28, 2011 at 4:14 PM, Tanuj Jain wrote: > Hi, > Can anyone please tell where I could download *packages > org.apache.lucene.analysis.* *so that I could

lucene 3.1 contrib packages source code download

Hi, Can anyone please tell where I could download *packages org.apache.lucene.analysis.* *so that I could use them in lucene 3.1 version. I have *deprecated version* for the above mentioned package. Please tell from where I could get the contrib packages *source code* for lucene 3.1. Is there any o

Re: Immutable OpenBitSet?

> static void writer() { >f = new FinalFieldExample(); > } > static void reader() { >if (f != null) { > int i = f.x; // guaranteed to see 3 > int j = f.y; // could see 0 >} > } >} > In this snippet of code there's not even a guarant

Re: Immutable OpenBitSet?

On Thu, Apr 28, 2011 at 6:13 PM, Uwe Schindler wrote: > In general a *newly* created object that was not yet seen by any other > thread is always safe. This is why I said, set all bits in the ctor. This is > easy to understand: Before the ctor returns, the object's contents and all > references li

Are Okapi BM25 scores normalized into 0 and 1 ?

Is Okapi BM25 (its implementation in Lucene: nlp.uned.es/~jperezi/Lucene-BM25) returning back normalized query scores (in between 0 and 1) ? According to Okapi formula the final score should be normalized. Could you give some information about that ? thanks

Re: Immutable OpenBitSet?

> In general a *newly* created object that was not yet seen by any other > thread is always safe. This is why I said, set all bits in the ctor. This > is > easy to understand: Before the ctor returns, the object's contents and all > references like arrays are not seen by any other thread (that's >

RE: Immutable OpenBitSet?

In general a *newly* created object that was not yet seen by any other thread is always safe. This is why I said, set all bits in the ctor. This is easy to understand: Before the ctor returns, the object's contents and all references like arrays are not seen by any other thread (that's guaranteed).

Re: Immutable OpenBitSet?

Nader, John P, il 28/04/2011 00:24, ha scritto: Thanks. Your project looks interesting. We've got some duplicate home-grown stuff here that is similar. As far as thread-safety, if one thread initializes an OpenBitSet's by setting one or bits and then hands that off to another thread, the oth