lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley" <>
Subject Re: Poor performance "race condition" in FieldSortedHitQueue
Date Thu, 10 Aug 2006 01:57:13 GMT
On 8/9/06, Oliver Hutchison <> wrote:
> Yonik,
> > most easily implemented in Java5 via Future.
> I didn't use Java5 as I had a feeling that code is Lucene needs to compile
> on Java1.3 right?

Lucene 2 currently requires Java 1.4

It was really just a side comment - people have implemented these
blocking maps before, and I've seen it done with Java5 concurrency
things like Future - a natural fit.  The way you were going about it
is perfectly fine though.

> > I don't think you need two maps though, right?  just stick a
> > placeholder in the outer map.
> I'm using 2 maps mainly because it simplifies the implementation.
> Technically all that is needed is a singe map with a key that is a composite
> of index reader and field name however, given that there is also the
> requirement that we only maintain a weak reference to the index reader and
> the associated need to clean up the cache if the reader gets gc'd, it was
> simpler for me to simulate the composite key using the 2 maps.

Ah, right... I browsed your code a bit too fast.  It looks fine.

> On a related note it would be great if there was a way to plug a custom
> FieldCache implementation into Lucene, given there is a FieldCache interface
> it's a shame there's no way to actually provide an alternative
> implementation.

Well, there's FieldCache.DEFAULT

  /** Expert: The cache used internally by sorting and range query classes. */
  public static FieldCache DEFAULT = new FieldCacheImpl();

-Yonik Solr, the open-source Lucene search server

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message