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