[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
