[Oak origin/1.0] Apache Jackrabbit Oak matrix - Build # 600 - Failure

[Apache Jenkins Server]

The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#600)

Status: Failure

Check console output at 
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/600/ to view 
the results.

Changes:
[reschke] OAK-3729: RDBDocumentStore: implement RDB-specific VersionGC support 
for

[reschke] OAK-3750: BasicDocumentStoreTest: improve robustness of

 

Test results:
15 tests failed.
FAILED:  org.apache.jackrabbit.oak.jcr.query.SuggestTest.testSuggestSql

Error Message:
expected:<[[{term=in 2015 a red fox is still a fox,weight=1}, {term=in 2015 my 
fox is red, like mike's fox and john's fox,weight=1}]]> but was:<[]>

Stack Trace:
junit.framework.ComparisonFailure: expected:<[[{term=in 2015 a red fox is still 
a fox,weight=1}, {term=in 2015 my fox is red, like mike's fox and john's 
fox,weight=1}]]> but was:<[]>
at junit.framework.Assert.assertEquals(Assert.java:100)
at junit.framework.Assert.assertEquals(Assert.java:107)
at junit.framework.TestCase.assertEquals(TestCase.java:269)
at 
org.apache.jackrabbit.oak.jcr.query.SuggestTest.testSuggestSql(SuggestTest.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at 
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
at junit.framework.TestSuite.runTest(TestSuite.java:252)
at junit.framework.TestSuite.run(TestSuite.java:247)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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:115)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)


FAILED:  org.apache.jackrabbit.oak.jcr.query.SuggestTest.testSuggestXPath

Error Message:
expected:<[[{term=in 2015 a red fox is still a fox,weight=1}, {term=in 2015 my 
fox is red, like mike's fox and john's fox,weight=1}]]> but was:<[]>

Stack Trace:
junit.framework.ComparisonFailure: expected:<[[{term=in 2015 a red fox is still 
a fox,weight=1}, {term=in 2015 my fox is red, like mike's fox and john's 
fox,weight=1}]]> but was:<[]>
at junit.framework.Assert.assertEquals(Assert.java:100)
at junit.framework.Assert.assertEquals(Assert.java:107)
at junit.framework.TestCase.assertEquals(TestCase.java:269)
at 
org.apache.jackrabbit.oak.jcr.query.SuggestTest.testSuggestXPath(SuggestTest.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at 
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
at junit.framework.TestSuite.runTest(TestSuite.java:252)
at junit.framework.TestSuite.run(TestSuite.java:247)
at 

Oak releases around Christmas

[Davide Giannella]

Hello team,

we normally keep, as much as possible, a regular release cycle for the
various Oak versions.

Just wanted to let all the community know that as we're approaching
Christmas and most of us won't be in front of a screen we're skipping
one release cycle.

Please refer to jira for the updated dates around 1.3.13, 1.2.10 and 1.0.26

https://issues.apache.org/jira/browse/OAK/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel

Cheers
Davide

Re: fixVersions in jira

[Davide Giannella]

On 08/12/2015 16:06, Julian Reschke wrote:
>
> So what's the correct JIRA state for something that has been fixed in
> 1.3.x, which is intended to be backported to 1.2, but hasn't been
> backported yet? Can I still set that to "resolved"?

If the backport is part of the issue no you can't. If the backport is
difficult you can always mark the issue itself as resolved for 1.3 and
open a separate ticket for the backporting.

Davide

Re: [VOTE] Shut down oakcomm...@jackrabbit.apache.org mailing list

[Davide Giannella]

[X] +1, shut down oakcomm...@jackrabbit.apache.org

Davide

DocumentRDB builds time out on Jenkins

[Michael Dürig]

Hi,

In the last 5 build on our Jenkins instance [1] we always had one of the 
DocumentRDB jobs timing out [2]. This means the job didn't complete 
within 90 minutes. This is not because we are close to the limit as 
regular builds take roughly 30 minutes.


Is there anything we could do in the short term so we get at least 
useful results back from Jenkins again?


Michael

[1] https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
[2] https://issues.apache.org/jira/browse/OAK-3743

Re: fixVersions in jira

[Julian Reschke]

On 2015-12-09 10:33, Davide Giannella wrote:

On 08/12/2015 16:06, Julian Reschke wrote:


So what's the correct JIRA state for something that has been fixed in
1.3.x, which is intended to be backported to 1.2, but hasn't been
backported yet? Can I still set that to "resolved"?


If the backport is part of the issue no you can't. If the backport is
difficult you can always mark the issue itself as resolved for 1.3 and
open a separate ticket for the backporting.

Davide


Well, that would essentially triple the number of tickets for me, and 
will make it much harder later on to find what fix went where and when...



Best regards, Julian

Re: DocumentRDB builds time out on Jenkins

[Michael Dürig]

On 9.12.15 11:58 , Julian Reschke wrote:

On 2015-12-09 09:42, Michael Dürig wrote:


Hi,

In the last 5 build on our Jenkins instance [1] we always had one of the
DocumentRDB jobs timing out [2]. This means the job didn't complete
within 90 minutes. This is not because we are close to the limit as
regular builds take roughly 30 minutes.

Is there anything we could do in the short term so we get at least
useful results back from Jenkins again?

Michael

[1] https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
[2] https://issues.apache.org/jira/browse/OAK-3743



If it was always the same test then we should dig deeper. But as far as
I can tell, it isn't.


No it isn't a single test where it times out.



Do you have any suggestions?


Something must be way wrong as the build either takes ~30 minutes or it 
times out after 90 minutes. There is quite a difference here. Maybe we 
need to go through the log files and compare test execution times of 
individual tests between timed out and succeeded builds to get a clue.


Michael



Best regards, Julian

Re: svn commit: r1718848 - /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/NodeStateUtils.java

[Chetan Mehrotra]

On Wed, Dec 9, 2015 at 6:36 PM,   wrote:
> +private static String multiplier(String in, int times) {
> +StringBuilder sb = new StringBuilder();
> +for (int i = 0; i < times; i++) {
> +sb.append(in);
> +}
> +return sb.toString();
> +}
> +

May be use com.google.common.base.Strings#repeat?

Chetan Mehrotra

Re: DocumentRDB builds time out on Jenkins

[Julian Reschke]

On 2015-12-09 09:42, Michael Dürig wrote:


Hi,

In the last 5 build on our Jenkins instance [1] we always had one of the
DocumentRDB jobs timing out [2]. This means the job didn't complete
within 90 minutes. This is not because we are close to the limit as
regular builds take roughly 30 minutes.

Is there anything we could do in the short term so we get at least
useful results back from Jenkins again?

Michael

[1] https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
[2] https://issues.apache.org/jira/browse/OAK-3743



If it was always the same test then we should dig deeper. But as far as 
I can tell, it isn't.


Do you have any suggestions?

Best regards, Julian

Re: DocumentRDB builds time out on Jenkins

[Michael Dürig]

On 9.12.15 12:41 , Julian Reschke wrote:


Something must be way wrong as the build either takes ~30 minutes or it
times out after 90 minutes. There is quite a difference here. Maybe we
need to go through the log files and compare test execution times of
individual tests between timed out and succeeded builds to get a clue.
...


Any chance we could get Jenkins to get a thread dump when aborting the VM?


I don't think so. But maybe we can hack something in somehow on our side?

Michael



Best regards, Julian

Re: DocumentRDB builds time out on Jenkins

[Julian Reschke]

On 2015-12-09 12:02, Michael Dürig wrote:



On 9.12.15 11:58 , Julian Reschke wrote:

On 2015-12-09 09:42, Michael Dürig wrote:


Hi,

In the last 5 build on our Jenkins instance [1] we always had one of the
DocumentRDB jobs timing out [2]. This means the job didn't complete
within 90 minutes. This is not because we are close to the limit as
regular builds take roughly 30 minutes.

Is there anything we could do in the short term so we get at least
useful results back from Jenkins again?

Michael

[1] https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
[2] https://issues.apache.org/jira/browse/OAK-3743



If it was always the same test then we should dig deeper. But as far as
I can tell, it isn't.


No it isn't a single test where it times out.



Do you have any suggestions?


Something must be way wrong as the build either takes ~30 minutes or it
times out after 90 minutes. There is quite a difference here. Maybe we
need to go through the log files and compare test execution times of
individual tests between timed out and succeeded builds to get a clue.
...


Any chance we could get Jenkins to get a thread dump when aborting the VM?

Best regards, Julian

Re: svn commit: r1718848 - /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/state/NodeStateUtils.java

[Alex Parvulescu]

ah, good one! did not know about this, I'll replace the code

On Wed, Dec 9, 2015 at 2:20 PM, Chetan Mehrotra 
wrote:

> On Wed, Dec 9, 2015 at 6:36 PM,   wrote:
> > +private static String multiplier(String in, int times) {
> > +StringBuilder sb = new StringBuilder();
> > +for (int i = 0; i < times; i++) {
> > +sb.append(in);
> > +}
> > +return sb.toString();
> > +}
> > +
>
> May be use com.google.common.base.Strings#repeat?
>
> Chetan Mehrotra
>

Re: DocumentRDB builds time out on Jenkins

[Michael Dürig]

On 9.12.15 12:02 , Michael Dürig wrote:




Do you have any suggestions?


Something must be way wrong as the build either takes ~30 minutes or it
times out after 90 minutes. There is quite a difference here. Maybe we
need to go through the log files and compare test execution times of
individual tests between timed out and succeeded builds to get a clue.



Comparing test execution times for builds 593 and 595. The former timed 
out and the latter passed. Both ran on Java 1.8.


Running org.apache.jackrabbit.oak.jcr.ValueFactoryTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 66.774 sec

vs.

Running org.apache.jackrabbit.oak.jcr.MoveRemoveTest
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 22.893 sec


Running org.apache.jackrabbit.oak.jcr.query.QueryTest
Tests run: 27, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 541.876 sec

vs.

Running org.apache.jackrabbit.oak.jcr.query.QueryTest
Tests run: 27, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 48.32 sec

So it seems that for some reason sometimes tests run 3 - 5 times slower 
than normal, which with a usual build time of ~30 minutes bumps us over 
the 90 minutes build time out.


Michael


See:
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/595/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=unittesting/consoleFull
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/593/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_RDB,profile=unittesting/console

Re: jackrabbit-oak build #7043: Errored

[Angela Schreiber]

the failure as far as i can see is:

  Running org.apache.jackrabbit.oak.jcr.AsyncConflictsIT

  No output has been received in the last 10 minutes, this potentially
indicates a stalled build or something wrong with the build itself.
  The build has been terminated

i don't think this is related to the changes made.
kind regards
angela



On 09/12/15 17:58, "Travis CI"  wrote:

>Build Update for apache/jackrabbit-oak
>-
>
>Build: #7043
>Status: Errored
>
>Duration: 2173 seconds
>Commit: 88dccebec307c629e01980181745a67fe8b69813 (trunk)
>Author: Angela Schreiber
>Message: OAK-3759 : UserManager.onCreate is not omitted for system users
>in case of XML import
>
>git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1718873
>13f79535-47bb-0310-9956-ffa450edef68
>
>View the changeset:
>https://github.com/apache/jackrabbit-oak/compare/99579567bf7b...88dccebec3
>07
>
>View the full build log and details:
>https://travis-ci.org/apache/jackrabbit-oak/builds/95828009
>
>--
>sent by Jukka's Travis notification gateway

jackrabbit-oak build #7043: Errored

[Travis CI]

Build Update for apache/jackrabbit-oak
-

Build: #7043
Status: Errored

Duration: 2173 seconds
Commit: 88dccebec307c629e01980181745a67fe8b69813 (trunk)
Author: Angela Schreiber
Message: OAK-3759 : UserManager.onCreate is not omitted for system users in 
case of XML import

git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1718873 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/jackrabbit-oak/compare/99579567bf7b...88dccebec307

View the full build log and details: 
https://travis-ci.org/apache/jackrabbit-oak/builds/95828009

--
sent by Jukka's Travis notification gateway