On 25 Nov, Uwe Schindler wrote: > I would really not see this as a real test failure. The test assumes that a > compound file index is slower during indexing, which is normally so. But > maybe the scheduler of your O/S did something strange at the time the test > ran and made it take longer to index without compound file. Is it > reproducible?
I don't know. But it's a quad core machine, perhaps something is done in parallel. Helmut. > > In my opinion, the test is invalid, it just shows something that happens > most of the time, but asserting it is wrong. > > I looked at the Java Version of the test: > http://java.codefetch.com/example/in/LuceneInAction/src/lia/indexing/Compoun > dVersusMultiFileIndexTest.java > > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: [email protected] > > >> -----Original Message----- >> From: Helmut Jarausch [mailto:[email protected]] >> Sent: Wednesday, November 25, 2009 10:33 AM >> To: [email protected] >> Cc: Andi Vajda >> Subject: Re: [VOTE] Release Apache Lucene Java 3.0.0 (take #2) >> >> On 24 Nov, Andi Vajda wrote: >> > I built PyLucene trunk using Lucene Java source from the artifact's svn >> rev >> > and all unit tests and ported "Lucene in Action" tests pass. >> > >> > +1 ! >> > >> > Andi.. >> >> Many thanks, Andi. >> >> Here (AMD64, python-2.6.4) a single test fails >> java development with ant: 0.502968132496 >> junit in action: 0.812919199467 >> 0.812919199467: JUnit in Action >> 0.502968132496: Java Development with Ant >> /usr/bin/python samples/LuceneInAction/CompoundVersusMultiFileIndexTest.py >> F >> ====================================================================== >> FAIL: testTiming >> (lia.indexing.CompoundVersusMultiFileIndexTest.CompoundVersusMultiFileInde >> xTest) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/Work1/Obj/Python/pylucene- >> build/samples/LuceneInAction/lia/indexing/CompoundVersusMultiFileIndexTest >> .py", line 62, in testTiming >> self.assert_(cTiming > mTiming) >> AssertionError >> >> >> Hopefully, this isn't critical. >> What could be the reason? >> >> Thanks again, >> Helmut. >> >> -- >> Helmut Jarausch >> >> Lehrstuhl fuer Numerische Mathematik >> RWTH - Aachen University >> D 52056 Aachen, Germany > -- Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany
