Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1623 - Still Failing

2013-05-17 Thread Adrien Grand
Since the resolution of this failure doesn't look trivial (as there are several options), I opened https://issues.apache.org/jira/browse/LUCENE-5004. -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For

[JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1623 - Still Failing

2013-05-16 Thread Apache Jenkins Server
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java6/1623/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriterOnDiskFull.testImmediateDiskFull Error Message: did not hit disk full Stack Trace: java.lang.AssertionError: did not hit disk full at

Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1623 - Still Failing

2013-05-16 Thread Adrien Grand
I can reproduce this one. It seems to me that the problem is that MockDirectoryWrapper.getRecomputedSizeInBytes uses RAMFile.length although RAMFile.length is only set on flush or seek and is 0 until then? Should setFileLength be called after every write? On Thu, May 16, 2013 at 8:35 AM, Apache

Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1623 - Still Failing

2013-05-16 Thread Shai Erera
I hit a similar failure with the Replicator tests, or should I say did not hit the expected disk full. I added a test to TestMDW.testDiskFull (fixing copyBytes to fail on disk-full) but I put a comment on why you need to call flush(). Basically, you should call flush to ensure that bytes are not

Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1623 - Still Failing

2013-05-16 Thread Adrien Grand
On Thu, May 16, 2013 at 11:30 AM, Shai Erera ser...@gmail.com wrote: As long as bytes are buffered, I think it's OK to not hit disk-full... they never made it to the directory yet. Good point. So the test needs to call commit right after IndexWriter.add(Document) to make sure flush gets called,

Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1623 - Still Failing

2013-05-16 Thread Robert Muir
I dont get it. MDW wraps its IndexOutput so it knows... sounds like the counting is off. On Thu, May 16, 2013 at 6:24 AM, Adrien Grand jpou...@gmail.com wrote: On Thu, May 16, 2013 at 11:30 AM, Shai Erera ser...@gmail.com wrote: As long as bytes are buffered, I think it's OK to not hit

Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1623 - Still Failing

2013-05-16 Thread Adrien Grand
On Thu, May 16, 2013 at 1:58 PM, Robert Muir rcm...@gmail.com wrote: I dont get it. MDW wraps its IndexOutput so it knows... sounds like the counting is off. The problem is that RAMDirectory delays the counting. MockDirectoryWrapper.getRecomputedActualSizeInBytes sums all the lengths of the

Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1623 - Still Failing

2013-05-16 Thread Shai Erera
I think this exception should be thrown only when the bytes land in the Directory. I think that in general we buffer bytes before sending them to the actual IndexOutput? I don't know if this is done with RAMDir too i.e. that there isn't code out there that buffers its writes to any IndexOutput,

Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1623 - Still Failing

2013-05-16 Thread Robert Muir
On Thu, May 16, 2013 at 8:45 AM, Adrien Grand jpou...@gmail.com wrote: Using the Mock IndexOutput to track bytes is an option, but I was thinking it could be interesting too to see what happens with directories that buffer content so that the disk full exception happens in flush instead of

Re: [JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1623 - Still Failing

2013-05-16 Thread Shai Erera
Looking at the code, I think that today flush() cannot throw diskFullEx? MockIO checks for diskFull in writeBytes and copyBytes, using dir.sizeInBytes. So I think if you limit maxSize=5 and write 4 + 4 bytes, to a Directory with a buffer of 20 bytes, then both writeBytes will succeed (as