You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Simon Helsen <sh...@ca.ibm.com> on 2012/06/11 19:49:46 UTC
errors when running the tests?
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
TestTDBLoader3 (was: errors when running the tests?)
Posted by Andy Seaborne <an...@apache.org>.
On 12/06/12 00:08, Stephen Allen wrote:
> 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.
Partial Analysis:
The main command program does:
tdbloader3.exec()
-->
DatasetGraphTDB dsg = SetupTDB.buildDataset(location) ;
then closes the triples and quad tables in order to format the directory.
This creates the files in the directory.
Reoping them on Linux in
NodeTableBuilder2.buildNodeTableBPTreeIndex
causes them to be zero length but on Window as they are 8M or 8K (mapped
or direct modes) - looks like the files stay open and junk is seen even
when in direct mode.
Andy
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)
Re: errors when running the tests?
Posted by Stephen Allen <sa...@apache.org>.
On Mon, Jun 11, 2012 at 3:43 PM, Simon Helsen <sh...@ca.ibm.com> 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 <an...@apache.org>
> To:
> dev@jena.apache.org
> 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<rv...@yarcdata.com>
>> To:
>> "dev@jena.apache.org"<de...@jena.apache.org>
>> 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<sh...@ca.ibm.com>>
>> Reply-To: "dev@jena.apache.org<ma...@jena.apache.org>"
>> <de...@jena.apache.org>>
>> Date: Monday, June 11, 2012 11:35 AM
>> To: "dev@jena.apache.org<ma...@jena.apache.org>"
>> <de...@jena.apache.org>>
>> Cc: "dev@jena.apache.org<ma...@jena.apache.org>"
>> <de...@jena.apache.org>>
>> 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<rv...@yarcdata.com>>
>> To: "dev@jena.apache.org<ma...@jena.apache.org>"
>> <de...@jena.apache.org>>
>> 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"<shelsen@ca.ibm.com<
>> mailto:shelsen@ca.ibm.com>> 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
>>
>>
>>
>>
>>
>>
>
>
>
Re: ARQ / duration test failure.
Posted by Andy Seaborne <an...@apache.org>.
On 12/06/12 16:13, Simon Helsen wrote:
> I agree it is not a release stopper
>
> I actually don't think it is just the constants, although it clearly is
> related to the yearMonthDuration. E.g. the following 2 variations on the
> failing tests still fail with the same NPEs
>
> @Test*public**void*nv_add_22() {
> /testAdd/("'P1Y1M'^^xsd:yearMonthDuration",
> "'PT4H'^^xsd:dayTimeDuration", "'P1Y1MT4H'^^xsd:duration") ; }
> @Test*public**void*nv_sub_22() {
> /testSub/("'P2Y3M'^^xsd:yearMonthDuration",
> "'P1Y2M'^^xsd:yearMonthDuration", "'P1Y1M'^^xsd:yearMonthDuration") ; }
>
> It seems that duration arithmetic which involves xsd:yearMonthDuration
> is causing trouble unless it happens with a dateTime. E.g. the test
>
> @Test*public**void*nv_add_24() {
> /testAdd/("'2000-01-01T00:00:00Z'^^xsd:dateTime",
> "'P1Y1M'^^xsd:yearMonthDuration",
> "'2001-02-01T00:00:00Z'^^xsd:dateTime") ; }
>
> seems to succeed.
>
> I can look at filing a defect with the JRE folks, but if this is outside
> XSD requirements for durations, I doubt they'll do anything about it. Is
> there a reason Jena permits this behavior?
It's within the Java contract.
Note that the Java contract states that NPE is thrown iff the argument
is null. Otherwise the correct exception is IllegalStateException.
So NPE means NodevalueOps.additionNV
nv2.getDuration()
is null which track back to
"'PT4H'^^xsd:dayTimeDuration"
parses to a null duration on IBM and a Duration object on Sun.
That is from
Duration duration = xmlDatatypeFactory.newDuration(lex) ;
in NodeValue and hence DatatypeFactory.newInstance() is returning a
DatatypeFactory that can't parse PT4H as a dayTimeDuration. But then it
should throw IllegalArgumentException or UnsupportedOperationException.
Null is not a legal return value.
Given the way derived types work in XML,
Note the point of NPE is in xerces and the test set the Jena-shipped
version of Xerces so the versions of xerces are different and one has
been fixed if there is an endorsed jars. Otherwise, it is the inputs
being different hence DatatypeFactory or a under-java JVM bug, which is
unlikely.
Andy
>
> Simon
Re: ARQ / duration test failure.
Posted by Simon Helsen <sh...@ca.ibm.com>.
I agree it is not a release stopper
I actually don't think it is just the constants, although it clearly is
related to the yearMonthDuration. E.g. the following 2 variations on the
failing tests still fail with the same NPEs
@Test public void nv_add_22() { testAdd("'P1Y1M'^^xsd:yearMonthDuration",
"'PT4H'^^xsd:dayTimeDuration", "'P1Y1MT4H'^^xsd:duration" ) ; }
@Test public void nv_sub_22() { testSub("'P2Y3M'^^xsd:yearMonthDuration",
"'P1Y2M'^^xsd:yearMonthDuration", "'P1Y1M'^^xsd:yearMonthDuration" ) ; }
It seems that duration arithmetic which involves xsd:yearMonthDuration is
causing trouble unless it happens with a dateTime. E.g. the test
@Test public void nv_add_24() { testAdd(
"'2000-01-01T00:00:00Z'^^xsd:dateTime",
"'P1Y1M'^^xsd:yearMonthDuration",
"'2001-02-01T00:00:00Z'^^xsd:dateTime") ; }
seems to succeed.
I can look at filing a defect with the JRE folks, but if this is outside
XSD requirements for durations, I doubt they'll do anything about it. Is
there a reason Jena permits this behavior?
Simon
From:
Andy Seaborne <an...@apache.org>
To:
Simon Helsen/Toronto/IBM@IBMCA
Cc:
dev@jena.apache.org
Date:
06/12/2012 07:02 AM
Subject:
ARQ / duration test failure.
> 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.
tl;dr
I don't think this is a release stopper.
There are too many things elsewhere, unrelated, that have been fixed and
this is a localised problem (I hope!).
I tried: Sun Java 6 and the test pass:
java.runtime.name=OpenJDK Runtime Environment
java.vm.name=OpenJDK 64-Bit Server VM
java.runtime.version=1.6.0_24-b24
os.version=3.2.0-24-generic
java.version=1.6.0_24
I don't understand the relation of Sun and IBM JREs: the stacktrace has:
sun.reflect.NativeMethodAccessorImpl
in it.
org.apache.xerces.jaxp.datatype.AbstractDurationImpl.addDuration
Does the IBM JRE have an endorsed Xerces (it used to).
I wonder if the problem is not the operation itself at all, but the
setting up the constants.
The test is outside the strict XSD requirements for durations by one
reading: the test is a skew addition of yearMonth to a dayTime:
"'P1Y'^^xsd:yearMonthDuration" + "'PT4H'^^xsd:dayTimeDuration"
The test is supposed to pin down behaviour outside the strict spec.
I didn't understand what was meant to happen in this case so I went with
how the (Sun, java7) JRE hands it and it does add the quantities. The
values here are chosen so that they do not make it complicated - adding
26H to a yearMonth is complicated.
But NPE is not right outcome even if the XML processor is not accepting
this combination.
(Simon - I'll assume you'll deal with the report to the IBM JRE team)
> (Side question: when the single build fails because of a junit, it stops
> the rest - is there a way to continue?)
Not directly as far as I know because modules depend on previous ones.
You may be able to build+install with -DskipTests then run tests in a
module.
> 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 fixed that (TS_Factory) I hope yesterday, leaving the tdbloader3 to be
looked at.
Andy
ARQ / duration test failure.
Posted by Andy Seaborne <an...@apache.org>.
> 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.
tl;dr
I don't think this is a release stopper.
There are too many things elsewhere, unrelated, that have been fixed and
this is a localised problem (I hope!).
I tried: Sun Java 6 and the test pass:
java.runtime.name=OpenJDK Runtime Environment
java.vm.name=OpenJDK 64-Bit Server VM
java.runtime.version=1.6.0_24-b24
os.version=3.2.0-24-generic
java.version=1.6.0_24
I don't understand the relation of Sun and IBM JREs: the stacktrace has:
sun.reflect.NativeMethodAccessorImpl
in it.
org.apache.xerces.jaxp.datatype.AbstractDurationImpl.addDuration
Does the IBM JRE have an endorsed Xerces (it used to).
I wonder if the problem is not the operation itself at all, but the
setting up the constants.
The test is outside the strict XSD requirements for durations by one
reading: the test is a skew addition of yearMonth to a dayTime:
"'P1Y'^^xsd:yearMonthDuration" + "'PT4H'^^xsd:dayTimeDuration"
The test is supposed to pin down behaviour outside the strict spec.
I didn't understand what was meant to happen in this case so I went with
how the (Sun, java7) JRE hands it and it does add the quantities. The
values here are chosen so that they do not make it complicated - adding
26H to a yearMonth is complicated.
But NPE is not right outcome even if the XML processor is not accepting
this combination.
(Simon - I'll assume you'll deal with the report to the IBM JRE team)
> (Side question: when the single build fails because of a junit, it stops
> the rest - is there a way to continue?)
Not directly as far as I know because modules depend on previous ones.
You may be able to build+install with -DskipTests then run tests in a
module.
> 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 fixed that (TS_Factory) I hope yesterday, leaving the tdbloader3 to be
looked at.
Andy
Re: errors when running the tests?
Posted by Rob Vesse <rv...@yarcdata.com>.
On the note of the differing revision numbers svn info reports two
revision numbers:
1 - Revision which is the overall revision for the repository
2 - Last Changed Rev which is the most recent revision which changed the
current directory you are invoking the svn info command in/upon.
So for example running svn info in my current working copy (which is a
checkout of the trunk) but from within the jena-arq directory gives the
following output:
URL: https://rvesse@svn.apache.org/repos/asf/jena/trunk/jena-arq
Repository Root: https://rvesse@svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1348948
Node Kind: directory
Schedule: normal
Last Changed Author: andy
Last Changed Rev: 1348833
Last Changed Date: 2012-06-11 06:22:34 -0700 (Mon, 11 Jun 2012)
Rob
On 6/11/12 3:43 PM, "Simon Helsen" <sh...@ca.ibm.com> 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)
>
>
>
>From:
>Andy Seaborne <an...@apache.org>
>To:
>dev@jena.apache.org
>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<rv...@yarcdata.com>
>> To:
>> "dev@jena.apache.org"<de...@jena.apache.org>
>> 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<sh...@ca.ibm.com>>
>> Reply-To: "dev@jena.apache.org<ma...@jena.apache.org>"
>> <de...@jena.apache.org>>
>> Date: Monday, June 11, 2012 11:35 AM
>> To: "dev@jena.apache.org<ma...@jena.apache.org>"
>> <de...@jena.apache.org>>
>> Cc: "dev@jena.apache.org<ma...@jena.apache.org>"
>> <de...@jena.apache.org>>
>> 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<rv...@yarcdata.com>>
>> To: "dev@jena.apache.org<ma...@jena.apache.org>"
>> <de...@jena.apache.org>>
>> 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"<shelsen@ca.ibm.com<
>> mailto:shelsen@ca.ibm.com>> 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
>>
>>
>>
>>
>>
>>
>
>
>
Re: errors when running the tests?
Posted by Simon Helsen <sh...@ca.ibm.com>.
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)
From:
Andy Seaborne <an...@apache.org>
To:
dev@jena.apache.org
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<rv...@yarcdata.com>
> To:
> "dev@jena.apache.org"<de...@jena.apache.org>
> 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<sh...@ca.ibm.com>>
> Reply-To: "dev@jena.apache.org<ma...@jena.apache.org>"
> <de...@jena.apache.org>>
> Date: Monday, June 11, 2012 11:35 AM
> To: "dev@jena.apache.org<ma...@jena.apache.org>"
> <de...@jena.apache.org>>
> Cc: "dev@jena.apache.org<ma...@jena.apache.org>"
> <de...@jena.apache.org>>
> 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<rv...@yarcdata.com>>
> To: "dev@jena.apache.org<ma...@jena.apache.org>"
> <de...@jena.apache.org>>
> 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"<shelsen@ca.ibm.com<
> mailto:shelsen@ca.ibm.com>> 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
>
>
>
>
>
>
Re: errors when running the tests?
Posted by Andy Seaborne <an...@apache.org>.
(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<rv...@yarcdata.com>
> To:
> "dev@jena.apache.org"<de...@jena.apache.org>
> 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<sh...@ca.ibm.com>>
> Reply-To: "dev@jena.apache.org<ma...@jena.apache.org>"
> <de...@jena.apache.org>>
> Date: Monday, June 11, 2012 11:35 AM
> To: "dev@jena.apache.org<ma...@jena.apache.org>"
> <de...@jena.apache.org>>
> Cc: "dev@jena.apache.org<ma...@jena.apache.org>"
> <de...@jena.apache.org>>
> 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<rv...@yarcdata.com>>
> To: "dev@jena.apache.org<ma...@jena.apache.org>"
> <de...@jena.apache.org>>
> 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"<shelsen@ca.ibm.com<
> mailto:shelsen@ca.ibm.com>> 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
>
>
>
>
>
>
Re: errors when running the tests?
Posted by Simon Helsen <sh...@ca.ibm.com>.
thanks Rob
I did mvn clean package, But I tried with -U as well and it makes no
difference
From:
Rob Vesse <rv...@yarcdata.com>
To:
"dev@jena.apache.org" <de...@jena.apache.org>
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 <sh...@ca.ibm.com>>
Reply-To: "dev@jena.apache.org<ma...@jena.apache.org>"
<de...@jena.apache.org>>
Date: Monday, June 11, 2012 11:35 AM
To: "dev@jena.apache.org<ma...@jena.apache.org>"
<de...@jena.apache.org>>
Cc: "dev@jena.apache.org<ma...@jena.apache.org>"
<de...@jena.apache.org>>
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 <rv...@yarcdata.com>>
To: "dev@jena.apache.org<ma...@jena.apache.org>"
<de...@jena.apache.org>>
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" <shelsen@ca.ibm.com<
mailto:shelsen@ca.ibm.com>> 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
Re: errors when running the tests?
Posted by Rob Vesse <rv...@yarcdata.com>.
This is TestQueryExecutionTimeout.timeout_02() under Windows 7 64 bit VM
with Java 1.7.0_03
Yes testing timeouts is always a pain because it depends very much both on
the VM and the speed of the system they run on
Rob
On 6/11/12 2:24 PM, "Andy Seaborne" <an...@apache.org> wrote:
>On 11/06/12 20:39, Rob Vesse wrote:
>> 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.
>
>Getting the timeouts to work is a pain. Too long and the test become
>too long. too short and they go off in odd places (VM?)
>
>Which test?
>What setup?
>
> Andy
Re: errors when running the tests?
Posted by Andy Seaborne <an...@apache.org>.
On 11/06/12 20:39, Rob Vesse wrote:
> 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.
Getting the timeouts to work is a pain. Too long and the test become
too long. too short and they go off in odd places (VM?)
Which test?
What setup?
Andy
Re: errors when running the tests?
Posted by Rob Vesse <rv...@yarcdata.com>.
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 <sh...@ca.ibm.com>>
Reply-To: "dev@jena.apache.org<ma...@jena.apache.org>" <de...@jena.apache.org>>
Date: Monday, June 11, 2012 11:35 AM
To: "dev@jena.apache.org<ma...@jena.apache.org>" <de...@jena.apache.org>>
Cc: "dev@jena.apache.org<ma...@jena.apache.org>" <de...@jena.apache.org>>
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 <rv...@yarcdata.com>>
To: "dev@jena.apache.org<ma...@jena.apache.org>" <de...@jena.apache.org>>
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" <sh...@ca.ibm.com>> 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
Re: errors when running the tests?
Posted by Simon Helsen <sh...@ca.ibm.com>.
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 <rv...@yarcdata.com>
To:
"dev@jena.apache.org" <de...@jena.apache.org>
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" <sh...@ca.ibm.com> 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
Re: errors when running the tests?
Posted by Rob Vesse <rv...@yarcdata.com>.
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" <sh...@ca.ibm.com> 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