Can you describe exactly how the lockless commits affects this? Or could a reader be accessing the same RAMFile as a writer?

Seems that this really deviates from the simplicity of the write-once design of the original Lucene.

Do writers share the same underlying RAMDirectory? Seems this would cause a lot of contention.

Or point me to the relevant documentation.


On Nov 27, 2007, at 10:11 AM, Michael McCandless (JIRA) wrote:


[ https://issues.apache.org/jira/browse/LUCENE-1067? page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#action_12545885 ]

Michael McCandless commented on LUCENE-1067:
--------------------------------------------

OK I think this is just a thread safety issue on RAMFile.

That class has these comments:

// Only one writing stream with no concurrent reading streams, so no file synchronization required

// Direct read-only access to state supported for streams since a writing stream implies no other concurrent streams

which were true before lockless commits but after lockless commits are
not true, specifically for the segments_N and segments.gen files.

I think this fix is to make "ArrayList buffers" private (it's package
private now), add methods to get a buffer & get the number of buffers,
and make sure all methods that access "buffers" are synchronized.


TestStressIndexing has intermittent failures
--------------------------------------------

                Key: LUCENE-1067
URL: https://issues.apache.org/jira/browse/ LUCENE-1067
            Project: Lucene - Java
         Issue Type: Bug
           Reporter: Grant Ingersoll
           Assignee: Michael McCandless
           Priority: Minor
            Fix For: 2.3


See http://www.gossamer-threads.com/lists/lucene/java-dev/55092 copied below:
 OK, I have seen this twice in the last two days:
Testsuite: org.apache.lucene.index.TestStressIndexing
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 18.58
sec
[junit]
[junit] ------------- Standard Output ---------------
[junit] java.lang.NullPointerException
[junit] at
org.apache.lucene.store.RAMInputStream.readByte (RAMInputStream.java:67)
[junit] at
org.apache.lucene.store.IndexInput.readInt(IndexInput.java:66)
[junit] at org.apache.lucene.index.SegmentInfos
$FindSegmentsFile.run(SegmentInfos.java:544)
[junit] at
org
.apache
.lucene.index.DirectoryIndexReader.open(DirectoryIndexReader.java:63)
[junit] at
org.apache.lucene.index.IndexReader.open(IndexReader.java:209)
[junit] at
org.apache.lucene.index.IndexReader.open(IndexReader.java:192)
[junit] at
org.apache.lucene.search.IndexSearcher.<init>(IndexSearcher.java:56)
[junit] at org.apache.lucene.index.TestStressIndexing
$SearcherThread.doWork(TestStressIndexing.java:111)
[junit] at org.apache.lucene.index.TestStressIndexing
$TimedThread.run(TestStressIndexing.java:55)
[junit] ------------- ---------------- ---------------
[junit] Testcase:
testStressIndexAndSearching
(org.apache.lucene.index.TestStressIndexing): FAILED
[junit] hit unexpected exception in search1
[junit] junit.framework.AssertionFailedError: hit unexpected
exception in search1
[junit] at
org
.apache
.lucene.index.TestStressIndexing.runStressTest (TestStressIndexing.java:
159)
[junit] at
org
.apache
.lucene
.index
.TestStressIndexing
.testStressIndexAndSearching(TestStressIndexing.java:187)
[junit]
[junit]
[junit] Test org.apache.lucene.index.TestStressIndexing FAILED
Subsequent runs have, however passed. Has anyone else hit this on
trunk?
I am running using "ant clean test"
I'm on a Mac Pro 4 core, 4GB machine, if that helps at all. Not sure
how to reproduce at this point, but strikes me as a threading issue.
Oh joy!
I'll try to investigate more tomorrow to see if I can dream up a test
case.
-Grant

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



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to