Here is one stack trace: Full thread dump Java HotSpot(TM) Client VM (1.5.0_03-b07 mixed mode):
"Thread-6" prio=5 tid=0x6cf7a7f0 nid=0x59e50 waiting for monitor entry [0x6d2cf000..0x6d2cfd6c] at org.apache.lucene.index.SegmentReader.isDeleted(SegmentReader.java:241) - waiting to lock <0x04e40278> (a org.apache.lucene.index.SegmentReader) at org.apache.lucene.index.SegmentMergeInfo.<init>(SegmentMergeInfo.java:43) at org.apache.lucene.index.MultiTermEnum.<init>(MultiReader.java:277) at org.apache.lucene.index.MultiReader.terms(MultiReader.java:186) at org.apache.lucene.search.RangeQuery.rewrite(RangeQuery.java:75) at org.apache.lucene.search.BooleanQuery.rewrite(BooleanQuery.java:243) at org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:166) at org.apache.lucene.search.Query.weight(Query.java:84) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:158) at org.apache.lucene.search.Searcher.search(Searcher.java:67) at org.apache.lucene.search.QueryFilter.bits(QueryFilter.java:62) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:121) at org.apache.lucene.search.Hits.getMoreDocs(Hits.java:64) at org.apache.lucene.search.Hits.<init>(Hits.java:51) at org.apache.lucene.search.Searcher.search(Searcher.java:49) I've also seen it happen during sorting from: FieldSortedHitQueue.comparatorAuto -> FieldCacheImpl.getAuto() -> MultiReader.terms() -> MultiTermEnum.init() -> SegmentMergerInfo.init() -> SegmentReader.isDeleted() Peter On 10/11/05, Yonik Seeley <[EMAIL PROTECTED]> wrote: > > > We've been using this in production for a while and it fixed the > > extremely slow searches when there are deleted documents. > > Who was the caller of isDeleted()? There may be an opportunity for an easy > optimization to grab the BitVector and reuse it instead of repeatedly > calling isDeleted() on the IndexReader. > > -Yonik > Now hiring -- http://tinyurl.com/7m67g > >
