lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2095) Document not guaranteed to be found after write and commit
Date Wed, 25 Nov 2009 22:00:39 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782644#action_12782644
] 

Michael McCandless commented on LUCENE-2095:
--------------------------------------------

I can get this to fail fairly quickly, using 2 threads.

It's a thread safety issue of commit itself.  If you only allow 1 thread into commit at a
time I believe the issue won't happen.

It has to do with what thread #2 does when it enters commit and thread #1 is already in the
process of committing.  In this case thread #2 basically waits for thread #1 to finish and
then returns, whereas it should start its own new commit.

> Document not guaranteed to be found after write and commit
> ----------------------------------------------------------
>
>                 Key: LUCENE-2095
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2095
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 2.4.1, 2.9.1
>         Environment: Linux 64bit
>            Reporter: Sanne Grinovero
>         Attachments: lucene-stresstest.patch
>
>
> after same email on developer list:
> "I developed a stress test to assert that a new document containing a
> specific term "X" is always found after a commit on the IndexWriter.
> This works most of the time, but it fails under load in rare occasions.
> I'm testing with 40 Threads, both with a SerialMergeScheduler and a
> ConcurrentMergeScheduler, all sharing a common IndexWriter.
> Attached testcase is using a RAMDirectory only, but I verified a
> FSDirectory behaves in the same way so I don't believe it's the
> Directory implementation or the MergeScheduler.
> This test is slow, so I don't consider it a functional or unit test.
> It might give false positives: it doesn't always fail, sorry I
> couldn't find out how to make it more likely to happen, besides
> scheduling it to run for a longer time."
> I tested this to affect versions 2.4.1 and 2.9.1;

-- 
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message