lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-772) Lucene infinite loop? In FieldsReader.uncompress called from IndexSearcher.doc
Date Thu, 04 Jun 2009 10:51:07 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716233#action_12716233
] 

Uwe Schindler commented on LUCENE-772:
--------------------------------------

Corrumptions are not automatically fixed, but in 2.4.1 (end even before) there is a tool called
CheckIndex, which you can call with thex path to index. But it cannot really repair issues,
but can drop corrupt segments (parts of the index).

> Lucene infinite loop? In FieldsReader.uncompress called from IndexSearcher.doc
> ------------------------------------------------------------------------------
>
>                 Key: LUCENE-772
>                 URL: https://issues.apache.org/jira/browse/LUCENE-772
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Search
>    Affects Versions: 2.1
>         Environment: Linux (gentoo 2.6.17 at least), jdk 1.5.0_06 and _08 at least, tomcat
5.5. IndexSearcher searching index mounted via NFS; using new lockless commits... We're using
the 01-05-07 nightly build of lucene
>            Reporter: Arthur Smith
>             Fix For: 2.1
>
>
> Unfortunately I don't have a reproducible case of this (yet), but it's happened twice
now on our production servers in the past few days, after we switched to the new lockless
commits (thanks!). What we're seeing is the search thread running away in the middle of a
seemingly ordinary search, after several hundred thousand queries that worked just fine. The
search index is NFS mounted, and is updated every minute or so during the day by an indexing
process running on a separate server. We do get occasional I/O errors, but we catch and retry
and it seems ok after a few seconds.
> But twice now we've had run-away threads; the thread dump in both cases was caught in
the middle of java.util.zip.Inflater:
> "http-8080-3" daemon prio=1 tid=0x08294688 nid=0x1f0d runnable [0x1f17c000..0x1f17e0b0]
>         at java.util.zip.Inflater.inflateBytes(Native Method)
>         at java.util.zip.Inflater.inflate(Inflater.java:215)
>         - locked <0x3d73cba8> (a java.util.zip.Inflater)
>         at java.util.zip.Inflater.inflate(Inflater.java:232)
>         at org.apache.lucene.index.FieldsReader.uncompress(FieldsReader.java:388)
>         at org.apache.lucene.index.FieldsReader.addField(FieldsReader.java:222)
>         at org.apache.lucene.index.FieldsReader.doc(FieldsReader.java:105)
>         at org.apache.lucene.index.SegmentReader.document(SegmentReader.java:324)
>         - locked <0x3cefbdd8> (a org.apache.lucene.index.SegmentReader)       
at org.apache.lucene.index.MultiReader.document(MultiReader.java:108)
>         at org.apache.lucene.index.IndexReader.document(IndexReader.java:360)       
at org.apache.lucene.search.IndexSearcher.doc(IndexSearcher.java:84)
>         at org.apache.lucene.search.Hits.doc(Hits.java:104)
> [...]
> Any ideas what this could be? Thanks!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message