lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Austin (JIRA)" <>
Subject [jira] [Commented] (LUCENE-1720) TimeLimitedIndexReader and associated utility class
Date Tue, 16 Aug 2011 14:29:27 GMT


Carl Austin commented on LUCENE-1720:

Lucene 3.3 changed scoring in TermQuery (and others?) which means that TimeLimitedIndexReader
breaks query scoring, returning all scores as 0. This is because hash codes for the subreaders
are stored and reused. Unfortunately the getSequentialSubReaders uses a new wrapping object
each time and doesn't implement hash code in anyway, hence returning oid's. In my case I just
implemented hashcode in the TimeLimitedIndexReader, returning in.hashcode() and this fixed
the problem.

> TimeLimitedIndexReader and associated utility class
> ---------------------------------------------------
>                 Key: LUCENE-1720
>                 URL:
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: core/index
>            Reporter: Mark Harwood
>            Assignee: Mark Harwood
>            Priority: Minor
>         Attachments:,,,, LUCENE-1720.patch, LUCENE-1720.patch, LUCENE-1720.patch, Lucene-1720.patch,
> An alternative to TimeLimitedCollector that has the following advantages:
> 1) Any reader activity can be time-limited rather than just single searches e.g. the
document retrieve phase.
> 2) Times out faster (i.e. runaway queries such as fuzzies detected quickly before last
"collect" stage of query processing)
> Uses new utility timeout class that is independent of IndexReader.
> Initial contribution includes a performance test class but not had time as yet to work
up a formal Junit test.
> TimeLimitedIndexReader is coded as JDK1.5 but can easily be undone.

This message is automatically generated by JIRA.
For more information on JIRA, see:


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

View raw message