lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grant Ingersoll (JIRA)" <>
Subject [jira] Commented: (LUCENE-1033) FieldsReader Thread Safety
Date Wed, 31 Oct 2007 01:08:50 GMT


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:
>             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:
>     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(;
> 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:
For additional commands, e-mail:

View raw message