You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Apache Hudson Server <hu...@hudson.apache.org> on 2010/12/13 04:50:00 UTC
Lucene-trunk - Build # 1393 - Failure
Build: https://hudson.apache.org/hudson/job/Lucene-trunk/1393/
All tests passed
Build Log (for compile errors):
[...truncated 18397 lines...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Lucene-trunk - Build # 1395 - Still Failing
Posted by Apache Hudson Server <hu...@hudson.apache.org>.
Build: https://hudson.apache.org/hudson/job/Lucene-trunk/1395/
All tests passed
Build Log (for compile errors):
[...truncated 18384 lines...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene-trunk - Build # 1394 - Still Failing
Posted by Michael McCandless <lu...@mikemccandless.com>.
OK I just committed a fix. Hopefully this test stops failing now :)
Mike
On Tue, Dec 14, 2010 at 5:53 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> On Mon, Dec 13, 2010 at 11:50 PM, Shai Erera <se...@gmail.com> wrote:
>> I see that the test was changed yesterday, and perhaps it causes the
>> problem? Previously, the test had that code:
>>
>> // r might have changed because this is not a
>> // synchronized method. However we don't want
>> // to make it synchronized to test
>> // thread-safety of IndexReader.close().
>> // That's why we add refreshed also to
>> // readersToClose, because double closing is fine
>> if (refreshed != r) {
>> refreshed.close();
>> }
>> readersToClose.add(refreshed);
>>
>> And Mike changed it to:
>>
>> if (refreshed != r) {
>> refreshed.close();
>> }
>
> Yeah this comment made no sense to me, and neither did the double
> close. Ie on getting the refreshedReader we should simply close it
> and not add it to readersToClose.
>
>> --> Removing the comment + adding refreshed to readersToClose. Maybe adding
>> refreshed is still necessary?
>
> Adding to readersToClose shouldn't be needed if we close it right away.
>
>> I wasn't able to reproduce it on my environment though, so I'm not sure.
>> Anyway, besides that change, the rest of the changes seem harmless and
>> unrelated to the break (this one might not be related either, but it stands
>> out as a potential problem).
>
> This test failed yesterday (before my changes)... but actually now I
> think I know where the bug is!
>
> I think it's in PerFieldCodecWrapper -- its fieldsProducer method
> fails to close the sub-fieldsProducers that were opened on hitting an
> exception (which, in reopen, we can hit when writer is in the process
> of committing).
>
> I think we just need to add a try/finally there to close them... I'll do that.
>
> Mike
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene-trunk - Build # 1394 - Still Failing
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Mon, Dec 13, 2010 at 11:50 PM, Shai Erera <se...@gmail.com> wrote:
> I see that the test was changed yesterday, and perhaps it causes the
> problem? Previously, the test had that code:
>
> // r might have changed because this is not a
> // synchronized method. However we don't want
> // to make it synchronized to test
> // thread-safety of IndexReader.close().
> // That's why we add refreshed also to
> // readersToClose, because double closing is fine
> if (refreshed != r) {
> refreshed.close();
> }
> readersToClose.add(refreshed);
>
> And Mike changed it to:
>
> if (refreshed != r) {
> refreshed.close();
> }
Yeah this comment made no sense to me, and neither did the double
close. Ie on getting the refreshedReader we should simply close it
and not add it to readersToClose.
> --> Removing the comment + adding refreshed to readersToClose. Maybe adding
> refreshed is still necessary?
Adding to readersToClose shouldn't be needed if we close it right away.
> I wasn't able to reproduce it on my environment though, so I'm not sure.
> Anyway, besides that change, the rest of the changes seem harmless and
> unrelated to the break (this one might not be related either, but it stands
> out as a potential problem).
This test failed yesterday (before my changes)... but actually now I
think I know where the bug is!
I think it's in PerFieldCodecWrapper -- its fieldsProducer method
fails to close the sub-fieldsProducers that were opened on hitting an
exception (which, in reopen, we can hit when writer is in the process
of committing).
I think we just need to add a try/finally there to close them... I'll do that.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene-trunk - Build # 1394 - Still Failing
Posted by Shai Erera <se...@gmail.com>.
I see that the test was changed yesterday, and perhaps it causes the
problem? Previously, the test had that code:
// r might have changed because this is not a
// synchronized method. However we don't want
// to make it synchronized to test
// thread-safety of IndexReader.close().
// That's why we add refreshed also to
// readersToClose, because double closing is fine
if (refreshed != r) {
refreshed.close();
}
readersToClose.add(refreshed);
And Mike changed it to:
if (refreshed != r) {
refreshed.close();
}
--> Removing the comment + adding refreshed to readersToClose. Maybe adding
refreshed is still necessary?
I wasn't able to reproduce it on my environment though, so I'm not sure.
Anyway, besides that change, the rest of the changes seem harmless and
unrelated to the break (this one might not be related either, but it stands
out as a potential problem).
Shai
On Tue, Dec 14, 2010 at 4:40 AM, Apache Hudson Server <
hudson@hudson.apache.org> wrote:
> _1e_3.tis=1,
Lucene-trunk - Build # 1394 - Still Failing
Posted by Apache Hudson Server <hu...@hudson.apache.org>.
Build: https://hudson.apache.org/hudson/job/Lucene-trunk/1394/
1 tests failed.
REGRESSION: org.apache.lucene.index.TestIndexReaderReopen.testThreadSafety
Error Message:
MockDirectoryWrapper: cannot close: there are still open files: {_1e_3.tis=1, _1e_1.tis=1, _1e_2.pos=1, _1e_2.skp=1, _1e_1.skp=1, _1e_1.pos=1, _1e_2.frq=1, _1e_3.frq=1, _1e_2.tis=1, _1e_3.prx=1, _1e_2.pyl=1, _1e_2.doc=1, _1e_1.frq=1, _1e_1.doc=1, _1e_1.pyl=1}
Stack Trace:
java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are still open files: {_1e_3.tis=1, _1e_1.tis=1, _1e_2.pos=1, _1e_2.skp=1, _1e_1.skp=1, _1e_1.pos=1, _1e_2.frq=1, _1e_3.frq=1, _1e_2.tis=1, _1e_3.prx=1, _1e_2.pyl=1, _1e_2.doc=1, _1e_1.frq=1, _1e_1.doc=1, _1e_1.pyl=1}
at org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:387)
at org.apache.lucene.index.TestIndexReaderReopen.testThreadSafety(TestIndexReaderReopen.java:848)
at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1043)
at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:981)
Caused by: java.lang.RuntimeException: unclosed IndexInput
at org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:342)
at org.apache.lucene.store.Directory.openInput(Directory.java:122)
at org.apache.lucene.index.codecs.sep.SepPostingsReaderImpl.<init>(SepPostingsReaderImpl.java:70)
at org.apache.lucene.index.codecs.mockintblock.MockVariableIntBlockCodec.fieldsProducer(MockVariableIntBlockCodec.java:162)
at org.apache.lucene.index.PerFieldCodecWrapper$FieldsReader.<init>(PerFieldCodecWrapper.java:111)
at org.apache.lucene.index.PerFieldCodecWrapper.fieldsProducer(PerFieldCodecWrapper.java:191)
at org.apache.lucene.index.SegmentReader$CoreReaders.<init>(SegmentReader.java:131)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:527)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:504)
at org.apache.lucene.index.DirectoryReader.<init>(DirectoryReader.java:238)
at org.apache.lucene.index.DirectoryReader.doReopen(DirectoryReader.java:500)
at org.apache.lucene.index.DirectoryReader.access$000(DirectoryReader.java:48)
at org.apache.lucene.index.DirectoryReader$2.doBody(DirectoryReader.java:493)
at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:623)
at org.apache.lucene.index.DirectoryReader.doReopenNoWriter(DirectoryReader.java:488)
at org.apache.lucene.index.DirectoryReader.doReopen(DirectoryReader.java:446)
at org.apache.lucene.index.DirectoryReader.reopen(DirectoryReader.java:406)
at org.apache.lucene.index.TestIndexReaderReopen$9.run(TestIndexReaderReopen.java:769)
at org.apache.lucene.index.TestIndexReaderReopen$ReaderThread.run(TestIndexReaderReopen.java:886)
Build Log (for compile errors):
[...truncated 7184 lines...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org