[
https://issues.apache.org/jira/browse/LUCENE-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538963
]
Grant Ingersoll commented on LUCENE-1033:
-----------------------------------------
Can you post a test case of this that reproduces the problem?
> FieldsReader Thread Safety
> --------------------------
>
> Key: LUCENE-1033
> URL: https://issues.apache.org/jira/browse/LUCENE-1033
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Affects Versions: 2.2
> Environment: Java SDK 1.5.X, Linux & FreeBSD
> Reporter: Michael Klatt
> Priority: Minor
>
> From what I've read, the IndexSearcher is supposed to be thread safe.
> However, I don't think that the FieldsReader class (used by the IndexReader,
> and in turn used by the IndexSearcher) is thread safe. I have one
> IndexSearcher that I use with all my threads, and what appears to happen in
> Lucene 2.2 is that the same FieldsReader object is shared by all threads.
> The private "fieldStream" and "indexStream" attributes both have file
> pointers which makes them not thread-safe.
> For instance, in the "doc" method of FieldsReader:
> fieldsStream.seek(position);
> Document doc = new Document();
> int numFields = fieldsStream.readVInt();
> for (int i = 0; i < numFields; i++) {
> int fieldNumber = fieldsStream.readVInt();
> FieldInfo fi = fieldInfos.fieldInfo(fieldNumber);
> FieldSelectorResult acceptField = fieldSelector == null ?
> FieldSelectorResult.LOAD : fieldSelector.accept(fi.name);
> Another thread can seek to another position, so the readVInt calls are
> reading the wrong location in the stream. This is a race condition and only
> shows up when a lot of document field data is being read. When I
> synchronized the doc method, the problem went away. Another solution would
> be to use separate IndexSearchers, or to clone the FIeldsReader for each
> thread (I have not investigated either solution).
> I encountered this on Lucene 2.2, but I think the problem is still in the
> trunk. I was making a modification to the source code which caused the
> problem to be exaggerated, otherwise I probably wouldn't have discovered it.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
