You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Travis CI <ju...@apache.org> on 2014/01/27 18:29:44 UTC
jackrabbit-oak build #3173: Broken
Build Update for apache/jackrabbit-oak
-------------------------------------
Build: #3173
Status: Broken
Duration: 2043 seconds
Commit: f8f8d8e5966bf75f259fd531e376210b17913cfc (trunk)
Author: Michael Duerig
Message: OAK-1358: Oak should only create one default executor
git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1561721 13f79535-47bb-0310-9956-ffa450edef68
View the changeset: https://github.com/apache/jackrabbit-oak/compare/d6d5ddccf517...f8f8d8e5966b
View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/17706673
--
sent by Jukka's Travis notification gateway
Re: jackrabbit-oak build #3173: Broken
Posted by Michael Dürig <md...@apache.org>.
On 28.1.14 8:39 , Marcel Reutegger wrote:
> Hi,
>
>> Failed tests:
>> addNodes[2](org.apache.jackrabbit.oak.jcr.ConcurrentAddIT):
>> javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts
>> in /test/node4
>>
>> This doesn't seem to be related to my changes. Anyone else seen such
>> before? Does the content contributed by the test case actually ensure
>> that no conflicts arise? Otherwise such an exception is actually to be
>> expected and we should change the test.
>
> the test may cause conflicts in the property index. the expectation is
> that node store implementations are able to deal with those conflicts
> introduced by commit editors and retry the merge.
>
> maybe in this case one thread was unfortunate on each retry and
> eventually failed the merge.
So the failure would still be expected in this case but rather difficult
to distinguish from non expected merge failures. Let's keep an eye on
this to see whether we need to do something about it.
Michael
>
> Regards
> Marcel
>
Re: jackrabbit-oak build #3173: Broken
Posted by Michael Dürig <md...@apache.org>.
On 28.1.14 8:39 , Marcel Reutegger wrote:
> Hi,
>
>> Failed tests:
>> addNodes[2](org.apache.jackrabbit.oak.jcr.ConcurrentAddIT):
>> javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts
>> in /test/node4
>>
>> This doesn't seem to be related to my changes. Anyone else seen such
>> before? Does the content contributed by the test case actually ensure
>> that no conflicts arise? Otherwise such an exception is actually to be
>> expected and we should change the test.
>
> the test may cause conflicts in the property index. the expectation is
> that node store implementations are able to deal with those conflicts
> introduced by commit editors and retry the merge.
>
> maybe in this case one thread was unfortunate on each retry and
> eventually failed the merge.
So the failure would still be expected in this case but rather difficult
to distinguish from non expected merge failures. Let's keep an eye on
this to see whether we need to do something about it.
Michael
>
> Regards
> Marcel
>
Re: jackrabbit-oak build #3173: Broken
Posted by Michael Dürig <md...@apache.org>.
On 28.1.14 8:39 , Marcel Reutegger wrote:
> Hi,
>
>> Failed tests:
>> addNodes[2](org.apache.jackrabbit.oak.jcr.ConcurrentAddIT):
>> javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts
>> in /test/node4
>>
>> This doesn't seem to be related to my changes. Anyone else seen such
>> before? Does the content contributed by the test case actually ensure
>> that no conflicts arise? Otherwise such an exception is actually to be
>> expected and we should change the test.
>
> the test may cause conflicts in the property index. the expectation is
> that node store implementations are able to deal with those conflicts
> introduced by commit editors and retry the merge.
>
> maybe in this case one thread was unfortunate on each retry and
> eventually failed the merge.
So the failure would still be expected in this case but rather difficult
to distinguish from non expected merge failures. Let's keep an eye on
this to see whether we need to do something about it.
Michael
>
> Regards
> Marcel
>
RE: jackrabbit-oak build #3173: Broken
Posted by Marcel Reutegger <mr...@adobe.com>.
Hi,
> Failed tests:
> addNodes[2](org.apache.jackrabbit.oak.jcr.ConcurrentAddIT):
> javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts
> in /test/node4
>
> This doesn't seem to be related to my changes. Anyone else seen such
> before? Does the content contributed by the test case actually ensure
> that no conflicts arise? Otherwise such an exception is actually to be
> expected and we should change the test.
the test may cause conflicts in the property index. the expectation is
that node store implementations are able to deal with those conflicts
introduced by commit editors and retry the merge.
maybe in this case one thread was unfortunate on each retry and
eventually failed the merge.
Regards
Marcel
Re: jackrabbit-oak build #3173: Broken
Posted by Michael Dürig <md...@apache.org>.
Failed tests:
addNodes[2](org.apache.jackrabbit.oak.jcr.ConcurrentAddIT):
javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts
in /test/node4
This doesn't seem to be related to my changes. Anyone else seen such
before? Does the content contributed by the test case actually ensure
that no conflicts arise? Otherwise such an exception is actually to be
expected and we should change the test.
Michael
On 27.1.14 6:29 , Travis CI wrote:
> Build Update for apache/jackrabbit-oak
> -------------------------------------
>
> Build: #3173
> Status: Broken
>
> Duration: 2043 seconds
> Commit: f8f8d8e5966bf75f259fd531e376210b17913cfc (trunk)
> Author: Michael Duerig
> Message: OAK-1358: Oak should only create one default executor
>
> git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1561721 13f79535-47bb-0310-9956-ffa450edef68
>
> View the changeset: https://github.com/apache/jackrabbit-oak/compare/d6d5ddccf517...f8f8d8e5966b
>
> View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/17706673
>
> --
> sent by Jukka's Travis notification gateway
>