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]
