You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "vijaykumarraja.grandhi (JIRA)" <ji...@apache.org> on 2010/08/25 14:41:17 UTC

[jira] Issue Comment Edited: (LUCENE-2095) Document not guaranteed to be found after write and commit

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

vijaykumarraja.grandhi edited comment on LUCENE-2095 at 8/25/10 8:41 AM:
-------------------------------------------------------------------------

Please help me. Slowly all my trails are getting dried out. failing to resolve multi threading with Lucene. It is getting deadlog. Always I am seeing some Write.Lock file inside Index folder.

      was (Author: gvkraj23):
    Please help me. Slowly all my trails are getting dried out. 
  
> 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
>            Assignee: Michael McCandless
>             Fix For: 2.9.2, 3.0.1, 4.0
>
>         Attachments: LUCENE-2095.patch, 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org