lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-442) TestIndexModifier.testIndexWithThreads is not valid?
Date Mon, 24 Oct 2005 02:48:05 GMT
    [ http://issues.apache.org/jira/browse/LUCENE-442?page=comments#action_12349910 ] 

Yonik Seeley commented on LUCENE-442:
-------------------------------------

I see a few issues:

1) A constant seed is used for reproducability:
  private Random random = new Random(101);		// constant seed for reproducability
But, it won't have that effect since the same random number generator is used across threads.

2) race condition between checking idStack.size() and calling pop()

3) non-atomic increment of the document id could lead to duplicates

IMO, the ideal multithreaded test would be designed to not use any synchronization at all,
making it easier to test if IndexModifier actually does all the synchronization it needs to.

> TestIndexModifier.testIndexWithThreads is not valid?
> ----------------------------------------------------
>
>          Key: LUCENE-442
>          URL: http://issues.apache.org/jira/browse/LUCENE-442
>      Project: Lucene - Java
>         Type: Bug
>   Components: Search
>     Versions: 1.9
>     Reporter: Hoss Man

>
> I recently started playing with the trunk of SVN, and noticed that intermitently, TestIndexModifier.testIndexWithThreads
(revision 292010) would fail.
> The basic premise of the test seems to be that 3 pairs of IndexThread instances can be
started in parallel, each pair using the same instance of IndexModifier to concurrently and
randomly add/delete/optimize a single FSDirectory index.  
> The test is considered a success if the sum of additions-deletions recorded by each pair
of threads equals the final docCount() for the IndexModifier instance used by that pair of
threads.
> Now I freely admit that I'm not 100% familiar with the code for IndexModifier, but at
a glance, the basic premise seems to be: 
>    a) If method for IndexWriter is called, open it if needed, close the IndexReader first
if needed.
>    b) if method for IndexReader is called, open it if needed, close the IndexWriter first
if needed.
> If I'm understnading that correctly, I see no reason to assume this test will pass. 

> It seems like there could be plenty of scenerios in which the number of additions-deletions
!= docCount(). The most trivial example I can think of is:
>    1) the first IndexThread instance which has a chance to run adds a document, and optimizes
before any other IndexThreads ever open the Directory.
>    2) a subsequent pair of IndexThread instances open their IndexModifier instance before
any documents are deleted.
>    3) the IndexThread instances from #2 do nothing but add documents
> ...that pair of IndexThreads is now garunteed to have recorded a differnet number of
additions then the docCount returned by their IndexModifier.
> Am I missing something, or should this test be removed?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
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