On Mon, Jun 11, 2012 at 3:43 PM, Simon Helsen <[email protected]> wrote: > I checked out the components separately. Note that this is currently > suggested in the documentation - > http://jena.apache.org/getting_involved/index.html -> perhaps it would be > good to document the single checkout as you suggest below. > > Trying a single checkout I get the revision number 1349027. I run into the > same ARQ problem (attached log file again) at first. However, I checked > and I was using IBM's JRE 7 (*) - I also tried with IBM's JRE 6 and the > same effect. I then tried with Sun's JRE 7 (**) and things worked. That is > not good of course. I understand this is an experimental feature, so > perhaps it won't affect us, but it would be good to understand why there > is a difference here. > > (Side question: when the single build fails because of a junit, it stops > the rest - is there a way to continue?) > > I did see the issue with tdbloader before as well, but it didn't write > anything in the log file and I had wrongly assumed that it was only a > consequence of the problem with TS_Factory. I attached the console output > below. The log file is still empty > > Simon > > (*) java version "1.7.0" > Java(TM) SE Runtime Environment (build pwa6470-20110906_01) > IBM J9 VM (build 2.6, JRE 1.7.0 Windows 7 amd64-64 20110810_88604 (JIT > enabled, > AOT enabled) > J9VM - R26_Java726_GA_20110810_1208_B88592 > JIT - r11_20110810_20466 > GC - R26_Java726_GA_20110810_1208_B88592 > J9CL - 20110810_88604) > JCL - 20110809_01 based on Oracle 7b147 > > (**) java version "1.7.0_04" > Java(TM) SE Runtime Environment (build 1.7.0_04-b22) > Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode) > > > Running tdb.TS_TDBLoader3 > 18:39:27 ERROR BPlusTreeRewriter :: **** Not the root: 1024 > com.hp.hpl.jena.tdb.index.bplustree.BPTreeException > at > com.hp.hpl.jena.tdb.index.bplustree.BPlusTreeRewriter.packIntoBPlusTr > ee(BPlusTreeRewriter.java:89) > at > org.apache.jena.tdb.store.bulkloader3.NodeTableBuilder2.buildNodeTabl > eBPTreeIndex(NodeTableBuilder2.java:296) > at > org.apache.jena.tdb.store.bulkloader3.NodeTableBuilder2.close(NodeTab > leBuilder2.java:172) > at tdb.tdbloader3.exec(tdbloader3.java:216) > at arq.cmdline.CmdMain.mainMethod(CmdMain.java:101) > at arq.cmdline.CmdMain.mainRun(CmdMain.java:63) > at arq.cmdline.CmdMain.mainRun(CmdMain.java:50) > at tdb.tdbloader3.main(tdbloader3.java:108) > at tdb.TestTDBLoader3.run(TestTDBLoader3.java:120) > at tdb.TestTDBLoader3.test(TestTDBLoader3.java:88) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(Framework > Method.java:44) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCal > lable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMe > thod.java:41) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMet > hod.java:20) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores. > java:28) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun > ner.java:69) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun > ner.java:48) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.runners.ParentRunner.run(ParentRunner.java:292) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:24) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.runners.ParentRunner.run(ParentRunner.java:292) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:24) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.runners.ParentRunner.run(ParentRunner.java:292) > at > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provide > r.java:236) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4 > Provider.java:134) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider > .java:113) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray( > ReflectionUtils.java:189) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke > (ProviderFactory.java:165) > at > org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(Provi > derFactory.java:85) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(Fork > edBooter.java:103) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java: > 74) > >
I have seen this TDB test failure on Windows for a while. I believe it is caused by the notorious JVM bug that doesn't allow the memory mapped file to be deleted by the test, which then attempts to create a new one in the same location. -Stephen > > From: > Andy Seaborne <[email protected]> > To: > [email protected] > Date: > 06/11/2012 05:23 PM > Subject: > Re: errors when running the tests? > > > > (How can the svn version numbers be different?) > > Building a single checkout of the jena/trunk, I do not see the ARQ test > failure. The other legitimate way to build is from the source-release > or from the tagged release tree. > > svn co http://svn.apache.org/repos/asf/jena/trunk/ JENA > cd JENA > mvn clean install ##NB "install" > > I do not get an ARQ failure. Looking at the test it's addition of > durations so (1) not critical (new feature) and (2) getting the XML > Datatype support to work was an experience anyway. > > I used a java7 system: Sun Java 1.7.0 b147 > > What are you using? > > I see a problem with tdbloader3 tests on windows, but not your report. > Your may be a failure to clean up and I've rejigged that bit. > > Andy > > PS I did see a failure in jena-core - but rerunning "mvn clean install" > and it went away. This is rather worrying. > > > > and I had noticed the same > > problem last Friday. > > <!!!!!/> > > > On 11/06/12 21:29, Simon Helsen wrote: >> thanks Rob >> >> I did mvn clean package, But I tried with -U as well and it makes no >> difference >> >> >> >> >> From: >> Rob Vesse<[email protected]> >> To: >> "[email protected]"<[email protected]> >> Date: >> 06/11/2012 03:42 PM >> Subject: >> Re: errors when running the tests? >> >> >> >> Ok so revisions match up so we are talking the same code. >> >> I can't comment on the TDB errors not knowing that part of the codebase >> but the ARQ failures look to do with some XSD stuff which I know Andy >> worked on recently. Did you do a simple mvn clean package or did you do > a >> mvn clean package ?U to force updates of all dependencies. That is >> unlikely to magically fix things but occasionally it does. >> >> Interestingly when I fire up the Windows 7 VM and do this I see 1 test >> failure on ARQ related to a timeout not occurring which I'm not sure > what >> the culprit of is but not the two failures you see. >> >> For TDB I do see the same failures as you, as I said I can't help > diagnose >> those so will have to defer to Andy on that >> >> Rob >> >> From: Simon Helsen<[email protected]<mailto:[email protected]>> >> Reply-To: "[email protected]<mailto:[email protected]>" >> <[email protected]<mailto:[email protected]>> >> Date: Monday, June 11, 2012 11:35 AM >> To: "[email protected]<mailto:[email protected]>" >> <[email protected]<mailto:[email protected]>> >> Cc: "[email protected]<mailto:[email protected]>" >> <[email protected]<mailto:[email protected]>> >> Subject: Re: errors when running the tests? >> >> I picked up the revision this morning EST and I had noticed the same >> problem last Friday. The revision number on arq is 1348833 and on tdb it >> is 1348829 >> >> I have attached the relevant error reports >> >> Simon >> >> >> >> >> >> >> >> From: Rob Vesse<[email protected]<mailto:[email protected]>> >> To: "[email protected]<mailto:[email protected]>" >> <[email protected]<mailto:[email protected]>> >> Date: 06/11/2012 02:10 PM >> Subject: Re: errors when running the tests? >> >> ________________________________ >> >> >> >> I can't speak for other committers but I'm not seeing any test failures >> but then I like most of the other committers run on non-Windows > platforms >> (OS X in my case) >> >> Maven uses the surefire plugin to run unit tests and you can find > reports >> under target/surefire-reports for individual modules. >> >> I know Andy has made a ton of commits lately and there were some notes > in >> the log about enabling and re-enabling some failing tests during some of >> his development work around addressing the TDB issues. What revision > are >> you on precisely? Svn reports 1348948 for me. Is it possible you > picked >> up a revision that was during the time Andy was doing his work? >> >> Rob >> >> >> >> On 6/11/12 10:49 AM, "Simon Helsen"<[email protected]< >> mailto:[email protected]>> wrote: >> >>> Hi, >>> >>> When I update my Jena projects with svn and then run mvn clean package, > I >>> am seeing junit errors in ARQ and TDB. I am running this on Windows > 7/64 >>> bit. Does anyone else see this? It seems to me that it is questionable > to >>> release Jena if not all junits run through >>> >>> Is there a way to produce log files when I run the tests? That way I > can >>> easier share what I am seeing >>> >>> Simon >> >> >> >> >> >> > > >
