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) Index corruption can cause infinite spin loop when Lucene attempts to incorrectly uncompress fields
Date Tue, 18 Sep 2012 22:00:08 GMT

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

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

I don't think we need to keep this issue open. It is no longer possible to create compressed
fields, Lucene 3.x can only read them. If they are corrupt there is nothing we can do to fix
it as this is a bug in JDK.

I would close this as won't fix.
                
> Index corruption can cause infinite spin loop when Lucene attempts to incorrectly uncompress
fields
> ---------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-772
>                 URL: https://issues.apache.org/jira/browse/LUCENE-772
>             Project: Lucene - Core
>          Issue Type: Bug
>          Components: core/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: 3.6.2
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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


Mime
View raw message