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/10/05 16:34:25 UTC
initial test results
We did some initial tests with one of our clients and there are no obvious
functional regressions compared to 2.7.1. We also did not observe any
major performance regressions and in fact, observed slight to significant
write improvements (heavily depending on the scenario). We'll keep you
posted if we find anything else. Our baseline for comparison is 2.7.1
Simon
Re: running dev tests
Posted by Simon Helsen <sh...@ca.ibm.com>.
I can confirm that the IBM JRE has been fixed since their Java 7, Service
Release 1. I just tested it
Simon
From:
Andy Seaborne <an...@apache.org>
To:
dev@jena.apache.org
Date:
10/11/2012 06:22 AM
Subject:
Re: running dev tests
I've added protected calls the real test part for nv_sub_22 as well.
On 10/10/12 21:27, Simon Helsen wrote:
> Andy,
>
> I vaguely recall this was also discussed at the time.
>
> I just opened an internal defect, but I am not sure what it will take to
> get a fix since we are currently not blocked by this ourselves. I am not
> aware of our clients using xsd:yearMonthDuration, although that can
change
> of course. We'll see what they say.
Andy
Re: running dev tests
Posted by Andy Seaborne <an...@apache.org>.
I've added protected calls the real test part for nv_sub_22 as well.
On 10/10/12 21:27, Simon Helsen wrote:
> Andy,
>
> I vaguely recall this was also discussed at the time.
>
> I just opened an internal defect, but I am not sure what it will take to
> get a fix since we are currently not blocked by this ourselves. I am not
> aware of our clients using xsd:yearMonthDuration, although that can change
> of course. We'll see what they say.
Andy
Re: running dev tests
Posted by Simon Helsen <sh...@ca.ibm.com>.
Andy,
I vaguely recall this was also discussed at the time.
I just opened an internal defect, but I am not sure what it will take to
get a fix since we are currently not blocked by this ourselves. I am not
aware of our clients using xsd:yearMonthDuration, although that can change
of course. We'll see what they say.
As for the experiments:
1) qexpr "'P2Y0M'^^xsd:yearMonthDuration - 'P1Y0M'^^xsd:yearMonthDuration"
: fails with the same NPE
2) qexpr "'P2Y4M'^^xsd:yearMonthDuration - 'P1Y2M'^^xsd:yearMonthDuration"
: fails with the same NPE
3) qexpr "'P1DT10H'^^xsd:dayTimeDuration - 'P1DT5H'^^xsd:dayTimeDuration
": works fine
4)qexpr "'P2Y'^^xsd:yearMonthDuration + 'P1Y'^^xsd:yearMonthDuration":
fails with the same NPE
5)qexpr "'P2Y0M'^^xsd:yearMonthDuration + 'P1Y0M'^^xsd:yearMonthDuration":
fails with the same NPE
6)qexpr "'P2Y4M'^^xsd:yearMonthDuration + 'P1Y2M'^^xsd:yearMonthDuration":
fails with the same NPE
7)qexpr "'P1DT10H'^^xsd:dayTimeDuration + 'P1DT5H'^^xsd:dayTimeDuration ":
works fine
So, the problem seems to sit in xsd:yearMonthDuration
Simon
From:
Andy Seaborne <an...@apache.org>
To:
dev@jena.apache.org
Date:
10/10/2012 03:27 PM
Subject:
Re: running dev tests
On 10/10/12 19:06, Simon Helsen wrote:
> thanks Andy. Now, I repeated the process with the latest, but there are
2
> tests which suffer from the same problem and it looks like the check was
> added for one of them and it behaves as expected. This is what I see on
> the console:
>
> Running com.hp.hpl.jena.sparql.expr.TS_Expr
> 14:03:33 WARN TestNodeValueOps :: **** IBM JVM does not
support
> xsd:ye
> arMonthDuration_xsd:dayTimeDuration
Good
> Tests run: 1023, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.75
> sec <<<
> FAILURE!
Bad. I was too quick fixing one ... but hold on: nv_sub_22 is
'P2Y'^^xsd:yearMonthDuration - 'P1Y'^^xsd:yearMonthDuration
which is XSD F&O section 10.6.2 op:subtract-yearMonthDurations
i.e. legal and defined.
is there a bug report to IBM Java about this?
Could you try the following expressions with arq.qexpr:
# sub_22
qexpr "'P2Y'^^xsd:yearMonthDuration - 'P1Y'^^xsd:yearMonthDuration"
# More fully specified
qexpr "'P2Y0M'^^xsd:yearMonthDuration - 'P1Y0M'^^xsd:yearMonthDuration"
# year and month
qexpr "'P2Y4M'^^xsd:yearMonthDuration - 'P1Y2M'^^xsd:yearMonthDuration"
# day-time
qexpr "'P1DT10H'^^xsd:dayTimeDuration - 'P1DT5H'^^xsd:dayTimeDuration "
The "+" versions should work as well:
qexpr "'P2Y'^^xsd:yearMonthDuration + 'P1Y'^^xsd:yearMonthDuration"
# More fully specified
qexpr "'P2Y0M'^^xsd:yearMonthDuration + 'P1Y0M'^^xsd:yearMonthDuration"
# year and month
qexpr "'P2Y4M'^^xsd:yearMonthDuration + 'P1Y2M'^^xsd:yearMonthDuration"
# day-time
qexpr "'P1DT10H'^^xsd:dayTimeDuration + 'P1DT5H'^^xsd:dayTimeDuration "
Andy
>
>
>
------------------------------------------------------------------------------
> Test set: com.hp.hpl.jena.sparql.expr.TS_Expr
>
-------------------------------------------------------------------------------
> Tests run: 1023, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.751
> sec <<< FAILURE!
> nv_sub_22(com.hp.hpl.jena.sparql.expr.TestNodeValueOps) Time elapsed:
> 0.006 sec <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.xerces.jaxp.datatype.AbstractDurationImpl.addDuration(Unknown
> Source)
> at
> org.apache.xerces.jaxp.datatype.AbstractDurationImpl.add(Unknown Source)
> at javax.xml.datatype.Duration.subtract(Unknown Source)
> at
>
com.hp.hpl.jena.sparql.expr.nodevalue.NodeValueOps.subtractionNV(NodeValueOps.java:185)
> at
>
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testSub(TestNodeValueOps.java:155)
> at
>
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testSub(TestNodeValueOps.java:147)
> at
>
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.nv_sub_22(TestNodeValueOps.java:96)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:613)
> at
>
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
>
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
>
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
>
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
>
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
> at
>
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
>
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
> at
>
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
> at
>
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.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:88)
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:613)
> 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(ProviderFactory.java:85)
> at
>
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.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:
> 10/10/2012 09:31 AM
> Subject:
> Re: running dev tests
>
>
>
> On 10/10/12 14:06, Simon Helsen wrote:
>> maven version: 3.0.3 (I guess I could upgrade to 3.0.4, which seems to
> be
>> the latest)
>
> I'm running 3.0.4 (although my instinct is that this is not the issue
> because the error includes "maven-assembly-plugin:2.2.1" which is the
> same). No idea currently where the .* comes from.
>
>>
>> The IBM JRE can be detected like this:
>>
>> private boolean isIBMJRE() {
>> String vmName = System.getProperty("java.vm.name");
>> return vmName != null && vmName.equals("IBM J9 VM");
>> }
>>
>
> Thanks - I've tweaked the test so it catches NPE and warns, but does not
> cause a test failure.
>
> If it is fixed so as to throw IllegalStateException, the test is silent.
>
> Andy
>
>
>
>
Re: running dev tests
Posted by Andy Seaborne <an...@apache.org>.
On 10/10/12 19:06, Simon Helsen wrote:
> thanks Andy. Now, I repeated the process with the latest, but there are 2
> tests which suffer from the same problem and it looks like the check was
> added for one of them and it behaves as expected. This is what I see on
> the console:
>
> Running com.hp.hpl.jena.sparql.expr.TS_Expr
> 14:03:33 WARN TestNodeValueOps :: **** IBM JVM does not support
> xsd:ye
> arMonthDuration_xsd:dayTimeDuration
Good
> Tests run: 1023, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.75
> sec <<<
> FAILURE!
Bad. I was too quick fixing one ... but hold on: nv_sub_22 is
'P2Y'^^xsd:yearMonthDuration - 'P1Y'^^xsd:yearMonthDuration
which is XSD F&O section 10.6.2 op:subtract-yearMonthDurations
i.e. legal and defined.
is there a bug report to IBM Java about this?
Could you try the following expressions with arq.qexpr:
# sub_22
qexpr "'P2Y'^^xsd:yearMonthDuration - 'P1Y'^^xsd:yearMonthDuration"
# More fully specified
qexpr "'P2Y0M'^^xsd:yearMonthDuration - 'P1Y0M'^^xsd:yearMonthDuration"
# year and month
qexpr "'P2Y4M'^^xsd:yearMonthDuration - 'P1Y2M'^^xsd:yearMonthDuration"
# day-time
qexpr "'P1DT10H'^^xsd:dayTimeDuration - 'P1DT5H'^^xsd:dayTimeDuration "
The "+" versions should work as well:
qexpr "'P2Y'^^xsd:yearMonthDuration + 'P1Y'^^xsd:yearMonthDuration"
# More fully specified
qexpr "'P2Y0M'^^xsd:yearMonthDuration + 'P1Y0M'^^xsd:yearMonthDuration"
# year and month
qexpr "'P2Y4M'^^xsd:yearMonthDuration + 'P1Y2M'^^xsd:yearMonthDuration"
# day-time
qexpr "'P1DT10H'^^xsd:dayTimeDuration + 'P1DT5H'^^xsd:dayTimeDuration "
Andy
>
>
> ------------------------------------------------------------------------------
> Test set: com.hp.hpl.jena.sparql.expr.TS_Expr
> -------------------------------------------------------------------------------
> Tests run: 1023, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.751
> sec <<< FAILURE!
> nv_sub_22(com.hp.hpl.jena.sparql.expr.TestNodeValueOps) Time elapsed:
> 0.006 sec <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.xerces.jaxp.datatype.AbstractDurationImpl.addDuration(Unknown
> Source)
> at
> org.apache.xerces.jaxp.datatype.AbstractDurationImpl.add(Unknown Source)
> at javax.xml.datatype.Duration.subtract(Unknown Source)
> at
> com.hp.hpl.jena.sparql.expr.nodevalue.NodeValueOps.subtractionNV(NodeValueOps.java:185)
> at
> com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testSub(TestNodeValueOps.java:155)
> at
> com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testSub(TestNodeValueOps.java:147)
> at
> com.hp.hpl.jena.sparql.expr.TestNodeValueOps.nv_sub_22(TestNodeValueOps.java:96)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:613)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.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:88)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:613)
> 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(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.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:
> 10/10/2012 09:31 AM
> Subject:
> Re: running dev tests
>
>
>
> On 10/10/12 14:06, Simon Helsen wrote:
>> maven version: 3.0.3 (I guess I could upgrade to 3.0.4, which seems to
> be
>> the latest)
>
> I'm running 3.0.4 (although my instinct is that this is not the issue
> because the error includes "maven-assembly-plugin:2.2.1" which is the
> same). No idea currently where the .* comes from.
>
>>
>> The IBM JRE can be detected like this:
>>
>> private boolean isIBMJRE() {
>> String vmName = System.getProperty("java.vm.name");
>> return vmName != null && vmName.equals("IBM J9 VM");
>> }
>>
>
> Thanks - I've tweaked the test so it catches NPE and warns, but does not
> cause a test failure.
>
> If it is fixed so as to throw IllegalStateException, the test is silent.
>
> Andy
>
>
>
>
Re: running dev tests
Posted by Simon Helsen <sh...@ca.ibm.com>.
thanks Andy. Now, I repeated the process with the latest, but there are 2
tests which suffer from the same problem and it looks like the check was
added for one of them and it behaves as expected. This is what I see on
the console:
Running com.hp.hpl.jena.sparql.expr.TS_Expr
14:03:33 WARN TestNodeValueOps :: **** IBM JVM does not support
xsd:ye
arMonthDuration_xsd:dayTimeDuration
Tests run: 1023, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.75
sec <<<
FAILURE!
------------------------------------------------------------------------------
Test set: com.hp.hpl.jena.sparql.expr.TS_Expr
-------------------------------------------------------------------------------
Tests run: 1023, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.751
sec <<< FAILURE!
nv_sub_22(com.hp.hpl.jena.sparql.expr.TestNodeValueOps) Time elapsed:
0.006 sec <<< ERROR!
java.lang.NullPointerException
at
org.apache.xerces.jaxp.datatype.AbstractDurationImpl.addDuration(Unknown
Source)
at
org.apache.xerces.jaxp.datatype.AbstractDurationImpl.add(Unknown Source)
at javax.xml.datatype.Duration.subtract(Unknown Source)
at
com.hp.hpl.jena.sparql.expr.nodevalue.NodeValueOps.subtractionNV(NodeValueOps.java:185)
at
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testSub(TestNodeValueOps.java:155)
at
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testSub(TestNodeValueOps.java:147)
at
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.nv_sub_22(TestNodeValueOps.java:96)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:613)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.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:88)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:613)
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(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.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:
10/10/2012 09:31 AM
Subject:
Re: running dev tests
On 10/10/12 14:06, Simon Helsen wrote:
> maven version: 3.0.3 (I guess I could upgrade to 3.0.4, which seems to
be
> the latest)
I'm running 3.0.4 (although my instinct is that this is not the issue
because the error includes "maven-assembly-plugin:2.2.1" which is the
same). No idea currently where the .* comes from.
>
> The IBM JRE can be detected like this:
>
> private boolean isIBMJRE() {
> String vmName = System.getProperty("java.vm.name");
> return vmName != null && vmName.equals("IBM J9 VM");
> }
>
Thanks - I've tweaked the test so it catches NPE and warns, but does not
cause a test failure.
If it is fixed so as to throw IllegalStateException, the test is silent.
Andy
Re: running dev tests
Posted by Andy Seaborne <an...@apache.org>.
On 10/10/12 14:06, Simon Helsen wrote:
> maven version: 3.0.3 (I guess I could upgrade to 3.0.4, which seems to be
> the latest)
I'm running 3.0.4 (although my instinct is that this is not the issue
because the error includes "maven-assembly-plugin:2.2.1" which is the
same). No idea currently where the .* comes from.
>
> The IBM JRE can be detected like this:
>
> private boolean isIBMJRE() {
> String vmName = System.getProperty("java.vm.name");
> return vmName != null && vmName.equals("IBM J9 VM");
> }
>
Thanks - I've tweaked the test so it catches NPE and warns, but does not
cause a test failure.
If it is fixed so as to throw IllegalStateException, the test is silent.
Andy
Re: running dev tests
Posted by Simon Helsen <sh...@ca.ibm.com>.
maven version: 3.0.3 (I guess I could upgrade to 3.0.4, which seems to be
the latest)
The IBM JRE can be detected like this:
private boolean isIBMJRE() {
String vmName = System.getProperty("java.vm.name");
return vmName != null && vmName.equals("IBM J9 VM");
}
From:
Andy Seaborne <an...@apache.org>
To:
dev@jena.apache.org
Date:
10/10/2012 08:52 AM
Subject:
Re: running dev tests
On 09/10/12 22:16, Simon Helsen wrote:
> ok, so I am running on Windows 7/64 bit and In my toplevel JENA
directory,
> I ran
maven version?
We are using the same version of the assembly plug in - 2.2.1
>
> mvn clean
> svn update
> mvn install package
(minor)
"mvn clean test" is enough to run the tests
> in ARQ, I ran into 2 issues during the ARQ tests, (see below), but I
> believe that is specific to IBM's JDK (both 6 and 7). So, I tried
> rerunning with Oracle's JDK 7 and then I run into the issue mentioned by
> Andy (i.e. tdb.TS_TDBLoader3). Now, when I run
>
> mvn install package -DskipTests=true
>
> I am hitting an issue building Fuseki (although the jars are created).
> This is what Maven spits out:
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.
> 2.1:single (create-server-assembly) on project jena-fuseki: Execution
> create-ser
> ver-assembly of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.2.1:single
> failed: Unexpected internal error near index 3
> [ERROR] .*\
> [ERROR] ^
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e swit
> ch.
Ug. Looks like a maven-ism. And Java is portable? Hmm.
Presumably the zip and/or tar.gz is not built. Assembly happens after
the jar artifacts are built.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please rea
> d the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutio
> nException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
>
> [ERROR] mvn <goals> -rf :jena-fuseki
>
> Not sure where to find more information. I don't understand the message.
Nor do I - good(ish) news it builds somewhere.
> Finally, this is what I get for ARQ tests when running with an IBM JDK
7:
>
>
-------------------------------------------------------------------------------
> Test set: com.hp.hpl.jena.sparql.expr.TS_Expr
>
-------------------------------------------------------------------------------
> Tests run: 1023, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.679
> sec <<< FAILURE!
> nv_add_22(com.hp.hpl.jena.sparql.expr.TestNodeValueOps) Time elapsed:
> 0.005 sec <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.xerces.jaxp.datatype.AbstractDurationImpl.addDuration(Unknown
> Source)
> at
> org.apache.xerces.jaxp.datatype.AbstractDurationImpl.add(Unknown Source)
> at
>
com.hp.hpl.jena.sparql.expr.nodevalue.NodeValueOps.additionNV(NodeValueOps.java:125)
> at
>
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testAdd(TestNodeValueOps.java:124)
> at
>
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testAdd(TestNodeValueOps.java:116)
> at
>
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.nv_add_22(TestNodeValueOps.java:44)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
This is IBM JDK specific (I think you've reported it before)
http://mail-archives.apache.org/mod_mbox/jena-dev/201206.mbox/%3C4FD7216A.3070008%40apache.org%3E
The test is
'P1Y'^^xsd:yearMonthDuration + 'PT4H'^^xsd:dayTimeDuration
which is not covered by the XSD specs (they do not define
yearMonthDuration + dayTimeDuration).
However, the javadoc for the operation does not forbid it and the
examples for Duration.add(Duration) suggest it is possible because Java
does not have separate types for the subtypes of duration.
The javadoc "spec" does allow IllegalStateException to be thrown.
NullPointerException does not count!
It could be coded around. I'd rather not remove the test because it's
not impossible in user data albeit a bit odd.
How can the code tell if it is running on an IBM JDK?
Andy
Re: running dev tests
Posted by Andy Seaborne <an...@apache.org>.
On 09/10/12 22:16, Simon Helsen wrote:
> ok, so I am running on Windows 7/64 bit and In my toplevel JENA directory,
> I ran
maven version?
We are using the same version of the assembly plug in - 2.2.1
>
> mvn clean
> svn update
> mvn install package
(minor)
"mvn clean test" is enough to run the tests
> in ARQ, I ran into 2 issues during the ARQ tests, (see below), but I
> believe that is specific to IBM's JDK (both 6 and 7). So, I tried
> rerunning with Oracle's JDK 7 and then I run into the issue mentioned by
> Andy (i.e. tdb.TS_TDBLoader3). Now, when I run
>
> mvn install package -DskipTests=true
>
> I am hitting an issue building Fuseki (although the jars are created).
> This is what Maven spits out:
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:2.
> 2.1:single (create-server-assembly) on project jena-fuseki: Execution
> create-ser
> ver-assembly of goal
> org.apache.maven.plugins:maven-assembly-plugin:2.2.1:single
> failed: Unexpected internal error near index 3
> [ERROR] .*\
> [ERROR] ^
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e swit
> ch.
Ug. Looks like a maven-ism. And Java is portable? Hmm.
Presumably the zip and/or tar.gz is not built. Assembly happens after
the jar artifacts are built.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please rea
> d the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutio
> nException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
>
> [ERROR] mvn <goals> -rf :jena-fuseki
>
> Not sure where to find more information. I don't understand the message.
Nor do I - good(ish) news it builds somewhere.
> Finally, this is what I get for ARQ tests when running with an IBM JDK 7:
>
> -------------------------------------------------------------------------------
> Test set: com.hp.hpl.jena.sparql.expr.TS_Expr
> -------------------------------------------------------------------------------
> Tests run: 1023, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.679
> sec <<< FAILURE!
> nv_add_22(com.hp.hpl.jena.sparql.expr.TestNodeValueOps) Time elapsed:
> 0.005 sec <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.xerces.jaxp.datatype.AbstractDurationImpl.addDuration(Unknown
> Source)
> at
> org.apache.xerces.jaxp.datatype.AbstractDurationImpl.add(Unknown Source)
> at
> com.hp.hpl.jena.sparql.expr.nodevalue.NodeValueOps.additionNV(NodeValueOps.java:125)
> at
> com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testAdd(TestNodeValueOps.java:124)
> at
> com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testAdd(TestNodeValueOps.java:116)
> at
> com.hp.hpl.jena.sparql.expr.TestNodeValueOps.nv_add_22(TestNodeValueOps.java:44)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
This is IBM JDK specific (I think you've reported it before)
http://mail-archives.apache.org/mod_mbox/jena-dev/201206.mbox/%3C4FD7216A.3070008%40apache.org%3E
The test is
'P1Y'^^xsd:yearMonthDuration + 'PT4H'^^xsd:dayTimeDuration
which is not covered by the XSD specs (they do not define
yearMonthDuration + dayTimeDuration).
However, the javadoc for the operation does not forbid it and the
examples for Duration.add(Duration) suggest it is possible because Java
does not have separate types for the subtypes of duration.
The javadoc "spec" does allow IllegalStateException to be thrown.
NullPointerException does not count!
It could be coded around. I'd rather not remove the test because it's
not impossible in user data albeit a bit odd.
How can the code tell if it is running on an IBM JDK?
Andy
running dev tests
Posted by Simon Helsen <sh...@ca.ibm.com>.
ok, so I am running on Windows 7/64 bit and In my toplevel JENA directory,
I ran
mvn clean
svn update
mvn install package
in ARQ, I ran into 2 issues during the ARQ tests, (see below), but I
believe that is specific to IBM's JDK (both 6 and 7). So, I tried
rerunning with Oracle's JDK 7 and then I run into the issue mentioned by
Andy (i.e. tdb.TS_TDBLoader3). Now, when I run
mvn install package -DskipTests=true
I am hitting an issue building Fuseki (although the jars are created).
This is what Maven spits out:
[INFO] --- maven-javadoc-plugin:2.8.1:jar (attach-javadocs) @ jena-fuseki
---
[INFO] Building jar:
D:\jfsDev\JENA\jena-fuseki\target\jena-fuseki-0.2.5-SNAPSHO
T-javadoc.jar
[INFO]
[INFO] --- maven-assembly-plugin:2.2.1:single (create-server-assembly) @
jena-fu
seki ---
[INFO] Reading assembly descriptor: assembly-server.xml
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] jena-parent ....................................... SUCCESS
[4.945s]
[INFO] jena-iri .......................................... SUCCESS
[13.147s]
[INFO] jena-core ......................................... SUCCESS
[1:15.668s]
[INFO] jena-arq .......................................... SUCCESS
[2:28.417s]
[INFO] jena-tdb .......................................... SUCCESS
[2:58.328s]
[INFO] jena-fuseki ....................................... FAILURE
[19.922s]
[INFO] apache-jena ....................................... SKIPPED
[INFO] Apache Jena ....................................... SKIPPED
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 7:20.932s
[INFO] Finished at: Tue Oct 09 17:08:38 EDT 2012
[INFO] Final Memory: 37M/259M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.
2.1:single (create-server-assembly) on project jena-fuseki: Execution
create-ser
ver-assembly of goal
org.apache.maven.plugins:maven-assembly-plugin:2.2.1:single
failed: Unexpected internal error near index 3
[ERROR] .*\
[ERROR] ^
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e swit
ch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please rea
d the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutio
nException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn <goals> -rf :jena-fuseki
Not sure where to find more information. I don't understand the message.
Finally, this is what I get for ARQ tests when running with an IBM JDK 7:
-------------------------------------------------------------------------------
Test set: com.hp.hpl.jena.sparql.expr.TS_Expr
-------------------------------------------------------------------------------
Tests run: 1023, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.679
sec <<< FAILURE!
nv_add_22(com.hp.hpl.jena.sparql.expr.TestNodeValueOps) Time elapsed:
0.005 sec <<< ERROR!
java.lang.NullPointerException
at
org.apache.xerces.jaxp.datatype.AbstractDurationImpl.addDuration(Unknown
Source)
at
org.apache.xerces.jaxp.datatype.AbstractDurationImpl.add(Unknown Source)
at
com.hp.hpl.jena.sparql.expr.nodevalue.NodeValueOps.additionNV(NodeValueOps.java:125)
at
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testAdd(TestNodeValueOps.java:124)
at
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testAdd(TestNodeValueOps.java:116)
at
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.nv_add_22(TestNodeValueOps.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:613)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.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:88)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:613)
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(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
nv_sub_22(com.hp.hpl.jena.sparql.expr.TestNodeValueOps) Time elapsed:
0.002 sec <<< ERROR!
java.lang.NullPointerException
at
org.apache.xerces.jaxp.datatype.AbstractDurationImpl.addDuration(Unknown
Source)
at
org.apache.xerces.jaxp.datatype.AbstractDurationImpl.add(Unknown Source)
at javax.xml.datatype.Duration.subtract(Unknown Source)
at
com.hp.hpl.jena.sparql.expr.nodevalue.NodeValueOps.subtractionNV(NodeValueOps.java:185)
at
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testSub(TestNodeValueOps.java:138)
at
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.testSub(TestNodeValueOps.java:130)
at
com.hp.hpl.jena.sparql.expr.TestNodeValueOps.nv_sub_22(TestNodeValueOps.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:613)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.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:88)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:613)
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(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
From:
Simon Helsen/Toronto/IBM@IBMCA
To:
dev@jena.apache.org
Date:
10/09/2012 10:26 AM
Subject:
Re: initial test results
given that there are pre-release activities going on, I'll check if I also
observe the issue around tdbloader3 or anything else for that matter.
Simon
From:
Simon Helsen/Toronto/IBM@IBMCA
To:
dev@jena.apache.org
Date:
10/09/2012 09:37 AM
Subject:
Re: initial test results
Andy,
no, sorry, when I say internal testing, I mean running internal junit
suites which you don't have access to as well as performance suites on top
of client products which has the same problem. Since everyone here can run
the regular Jena dev tests, I wasn't paying attention to them (but I
should -> the last time I ran it I had an issue with building Fuseki, but
I was too busy to investigate at that point)
Simon
From:
Andy Seaborne <an...@apache.org>
To:
dev@jena.apache.org
Date:
10/06/2012 02:37 PM
Subject:
Re: initial test results
On 05/10/12 15:34, Simon Helsen wrote:
> We did some initial tests with one of our clients and there are no
obvious
> functional regressions compared to 2.7.1. We also did not observe any
> major performance regressions and in fact, observed slight to
significant
> write improvements (heavily depending on the scenario). We'll keep you
> posted if we find anything else. Our baseline for comparison is 2.7.1
>
> Simon
>
Excellent - thanks.
I take it you didn't run the dev tests on Windows - there's some
bizarrity going on with tdbloader3 which I doubt is of any use to you --
see JENA -289 -- looks like it is a fault with the test, not the code,
and the code is tdbloader3 specific anyway.
Andy
Re: initial test results
Posted by Simon Helsen <sh...@ca.ibm.com>.
given that there are pre-release activities going on, I'll check if I also
observe the issue around tdbloader3 or anything else for that matter.
Simon
From:
Simon Helsen/Toronto/IBM@IBMCA
To:
dev@jena.apache.org
Date:
10/09/2012 09:37 AM
Subject:
Re: initial test results
Andy,
no, sorry, when I say internal testing, I mean running internal junit
suites which you don't have access to as well as performance suites on top
of client products which has the same problem. Since everyone here can run
the regular Jena dev tests, I wasn't paying attention to them (but I
should -> the last time I ran it I had an issue with building Fuseki, but
I was too busy to investigate at that point)
Simon
From:
Andy Seaborne <an...@apache.org>
To:
dev@jena.apache.org
Date:
10/06/2012 02:37 PM
Subject:
Re: initial test results
On 05/10/12 15:34, Simon Helsen wrote:
> We did some initial tests with one of our clients and there are no
obvious
> functional regressions compared to 2.7.1. We also did not observe any
> major performance regressions and in fact, observed slight to
significant
> write improvements (heavily depending on the scenario). We'll keep you
> posted if we find anything else. Our baseline for comparison is 2.7.1
>
> Simon
>
Excellent - thanks.
I take it you didn't run the dev tests on Windows - there's some
bizarrity going on with tdbloader3 which I doubt is of any use to you --
see JENA -289 -- looks like it is a fault with the test, not the code,
and the code is tdbloader3 specific anyway.
Andy
Re: initial test results
Posted by Simon Helsen <sh...@ca.ibm.com>.
Andy,
no, sorry, when I say internal testing, I mean running internal junit
suites which you don't have access to as well as performance suites on top
of client products which has the same problem. Since everyone here can run
the regular Jena dev tests, I wasn't paying attention to them (but I
should -> the last time I ran it I had an issue with building Fuseki, but
I was too busy to investigate at that point)
Simon
From:
Andy Seaborne <an...@apache.org>
To:
dev@jena.apache.org
Date:
10/06/2012 02:37 PM
Subject:
Re: initial test results
On 05/10/12 15:34, Simon Helsen wrote:
> We did some initial tests with one of our clients and there are no
obvious
> functional regressions compared to 2.7.1. We also did not observe any
> major performance regressions and in fact, observed slight to
significant
> write improvements (heavily depending on the scenario). We'll keep you
> posted if we find anything else. Our baseline for comparison is 2.7.1
>
> Simon
>
Excellent - thanks.
I take it you didn't run the dev tests on Windows - there's some
bizarrity going on with tdbloader3 which I doubt is of any use to you --
see JENA -289 -- looks like it is a fault with the test, not the code,
and the code is tdbloader3 specific anyway.
Andy
Re: initial test results
Posted by Andy Seaborne <an...@apache.org>.
On 05/10/12 15:34, Simon Helsen wrote:
> We did some initial tests with one of our clients and there are no obvious
> functional regressions compared to 2.7.1. We also did not observe any
> major performance regressions and in fact, observed slight to significant
> write improvements (heavily depending on the scenario). We'll keep you
> posted if we find anything else. Our baseline for comparison is 2.7.1
>
> Simon
>
Excellent - thanks.
I take it you didn't run the dev tests on Windows - there's some
bizarrity going on with tdbloader3 which I doubt is of any use to you --
see JENA -289 -- looks like it is a fault with the test, not the code,
and the code is tdbloader3 specific anyway.
Andy