Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Lucene: Java-Dev

[jira] Commented: (LUCENE-772) Lucene infinite loop? In FieldsReader.uncompress called from IndexSearcher.doc

 

 

Lucene java-dev RSS feed   Index | Next | Previous | View Threaded


jira at apache

Jan 12, 2007, 1:41 PM

Post #1 of 4 (434 views)
Permalink
[jira] Commented: (LUCENE-772) Lucene infinite loop? In FieldsReader.uncompress called from IndexSearcher.doc

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

Chuck Williams commented on LUCENE-772:
---------------------------------------

I had many concurrency problems with java.util.zip and ended up switching to jzlib (www.jcraft.com/jzlib/), which has the benefit of being a pure Java implementation that you can easily debug and modify if necessary. There were no performance degradations associated with the shift, and jzlib has been solid for me. This would require that you compress and decompress external to Lucene, but that can be much more efficient anyway (especially with LUCENE-362, although the patch in jira probably won't apply cleanly with current code).

Not sure this helps, but I'd bet your issue is somehow related to concurrency.


> 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
>
> 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 contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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


jira at apache

Jan 12, 2007, 1:45 PM

Post #2 of 4 (400 views)
Permalink
[jira] Commented: (LUCENE-772) Lucene infinite loop? In FieldsReader.uncompress called from IndexSearcher.doc [In reply to]

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

Arthur Smith commented on LUCENE-772:
-------------------------------------

By the way, this runaway behavior did happen after we caught 1 i/o exception and retried the query (we close the IndexSearcher and open a new one whenever we get an exception, or if isCurrent is false). Unfortunately I don't have details on the i/o exception - I'll try to get that if we can make it happen again.

After the i/o exception, the runaway thread was using 100% of the CPU for at least 40 minutes.

> 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
>
> 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 contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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


jira at apache

Jan 12, 2007, 2:18 PM

Post #3 of 4 (394 views)
Permalink
[jira] Commented: (LUCENE-772) Lucene infinite loop? In FieldsReader.uncompress called from IndexSearcher.doc [In reply to]

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

Arthur Smith commented on LUCENE-772:
-------------------------------------

Chuck - thanks - though IndexSearcher is supposed to be thread safe, so maybe it shouldn't be calling java.util.zip?

But now that I look again, we shouldn't have *any* compressed fields in our indexes! This has got to be an index corruption issue - we'll get the latest build out there and see if the recent fixes (LUCENE-140 in particular) help.

> 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
>
> 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 contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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


rengels at ix

Jan 12, 2007, 2:30 PM

Post #4 of 4 (399 views)
Permalink
Re: [jira] Commented: (LUCENE-772) Lucene infinite loop? In FieldsReader.uncompress called from IndexSearcher.doc [In reply to]

I think you are mistaken (in a sense).

ZipInputStream is thread-safe in as much as an InputStream is thread-
safe - which is isn't.

I think what you are most likely seeing is that you are attempting to
uncompress 'corrupted data' and the decompressor is getting confused
- thus the hang.


On Jan 12, 2007, at 4:18 PM, Arthur Smith (JIRA) wrote:

>
> [ https://issues.apache.org/jira/browse/LUCENE-772?
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel#action_12464372 ]
>
> Arthur Smith commented on LUCENE-772:
> -------------------------------------
>
> Chuck - thanks - though IndexSearcher is supposed to be thread
> safe, so maybe it shouldn't be calling java.util.zip?
>
> But now that I look again, we shouldn't have *any* compressed
> fields in our indexes! This has got to be an index corruption issue
> - we'll get the latest build out there and see if the recent fixes
> (LUCENE-140 in particular) help.
>
>> 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
>>
>> 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 contact one of the
> administrators: https://issues.apache.org/jira/secure/
> Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/
> software/jira
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe[at]lucene.apache.org
> For additional commands, e-mail: java-dev-help[at]lucene.apache.org
>


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

Lucene java-dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.