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 Angela Schreiber <an...@adobe.com> on 2016/03/16 12:39:29 UTC
Failing SegmentToJdbcTest.validateMigration
hi oak devs
i keep getting test failure with SegmentToJdbcTest.validateMigration
every now and then but can't reliably reproduce it when debugging
the test (as thomas can confirm ;-)).
stepping into the AbstractOak2OakTest and finally
RepositorySidegrade.copyState i actually see that the target NodeBuilder
that results from copyWorkspace doesn't have the jcr:mixinTypes
property copied from the src to the target, which consequently
(and rightfully) results in the first Root.commit to fail, because
the rep:policy node present in the test-content is considered
isolated (i.e. the /-tree doesn't have the mix:AccessControllable
mixin type set, which is pretty obvious if jcr:mixinTypes property
is not copied over).
who is familiar with RepositorySidegrade and could take a closer
look what is going wrong here? i run into this when testing the changes
attached to OAK-4119 but i fail to see how those changes should impact
the copy performed by RepositorySidegrade.
kind regards
angela
PS: i also found https://issues.apache.org/jira/browse/OAK-2714
mentioning the exact same test to fail on Jenkins.
Re: Failing SegmentToJdbcTest.validateMigration
Posted by Angela Schreiber <an...@adobe.com>.
Hi Tomek
I create https://issues.apache.org/jira/browse/OAK-4174
in order not to mix my modifications with the upgrade
code as i consider the @ignore mark just a temp workaround
in order to keep everyone and jenkins happy :-)
kind regards
angela
On 07/04/16 14:01, "Tomek Rekawek" <re...@adobe.com> wrote:
>Hello Angela,
>
>> On 07 Apr 2016, at 13:37, Angela Schreiber <an...@adobe.com> wrote:
>>
>> I will take the liberty to mark the test with an @Ignore tag when
>> committing my changes. What's your preferred way to investigate
>> this? Shall I clone the OAK-4119? Or do you want to take a closer
>> look once I am done such that you can actually experience the
>> failure?
>
>Feel free to commit your changes with the @Ignore annotation and ping me
>once the OAK-4119 is done - I'll look into the failing test then.
>
>Best regards,
>Tomek
>
>--
>Tomek Rękawek | Adobe Research | www.adobe.com
>rekawek@adobe.com
Re: Failing SegmentToJdbcTest.validateMigration
Posted by Tomek Rekawek <re...@adobe.com>.
Hello Angela,
> On 07 Apr 2016, at 13:37, Angela Schreiber <an...@adobe.com> wrote:
>
> I will take the liberty to mark the test with an @Ignore tag when
> committing my changes. What's your preferred way to investigate
> this? Shall I clone the OAK-4119? Or do you want to take a closer
> look once I am done such that you can actually experience the
> failure?
Feel free to commit your changes with the @Ignore annotation and ping me once the OAK-4119 is done - I’ll look into the failing test then.
Best regards,
Tomek
--
Tomek Rękawek | Adobe Research | www.adobe.com
rekawek@adobe.com
Re: Failing SegmentToJdbcTest.validateMigration
Posted by Angela Schreiber <an...@adobe.com>.
Hi Tomek
While I see that OAK-4128 has been resolved fixed, I still experience
a failing SegmentToJdbcTest.validateMigration test, with my pending
changes for OAK-4119.
I will take the liberty to mark the test with an @Ignore tag when
committing my changes. What's your preferred way to investigate
this? Shall I clone the OAK-4119? Or do you want to take a closer
look once I am done such that you can actually experience the
failure?
Kind regards
Angela
On 16/03/16 14:26, "Angela Schreiber" <an...@adobe.com> wrote:
>Hi Tomek
>
>Thanks a lot for the confirmation and the issue!
>
>Just as a side node: our Adobe internal repositories
>_always_ have a policy node at the root. If the sidegrade
>is likely to be used in real, productive environments
>this should IMO be considered a critical bug.
>
>Thanks and kind regards
>Angela
>
>
>On 16/03/16 14:00, "Tomek Rekawek" <re...@adobe.com> wrote:
>
>>Hello Angela,
>>
>>> On 16 Mar 2016, at 12:39, Angela Schreiber <an...@adobe.com> wrote:
>>>
>>> stepping into the AbstractOak2OakTest and finally
>>> RepositorySidegrade.copyState i actually see that the target
>>>NodeBuilder
>>> that results from copyWorkspace doesn't have the jcr:mixinTypes
>>> property copied from the src to the target, which consequently
>>
>>Indeed, it seems there's a bug, which causes the RepositorySidegrade to
>>skip the root node properties. I think the reason lies in the
>>calculateEffectiveIncludePaths() method, which produces an effective list
>>of paths to migrate. If we have a '/' in the input list, the method will
>>replace it with a list of '/' children and the root itself is removed
>>from the list.
>>
>>Similar issue is present in the RepositoryUpgrade, but it isn't so
>>dangerous there, as we create the root node anyway using an initializer.
>>
>>Created OAK-4128 to track this.
>>
>>However, the OAK-4128 is reproducible and present not only on the JDBC
>>destination, so I guess the random failures (including the ones on
>>Jenkins) are related to something else.
>>
>>Best regards,
>>Tomek
>>
>>--
>>Tomek Rękawek | Adobe Research | www.adobe.com
>>rekawek@adobe.com
>>
>
Re: Failing SegmentToJdbcTest.validateMigration
Posted by Angela Schreiber <an...@adobe.com>.
Hi Tomek
Thanks a lot for the confirmation and the issue!
Just as a side node: our Adobe internal repositories
_always_ have a policy node at the root. If the sidegrade
is likely to be used in real, productive environments
this should IMO be considered a critical bug.
Thanks and kind regards
Angela
On 16/03/16 14:00, "Tomek Rekawek" <re...@adobe.com> wrote:
>Hello Angela,
>
>> On 16 Mar 2016, at 12:39, Angela Schreiber <an...@adobe.com> wrote:
>>
>> stepping into the AbstractOak2OakTest and finally
>> RepositorySidegrade.copyState i actually see that the target NodeBuilder
>> that results from copyWorkspace doesn't have the jcr:mixinTypes
>> property copied from the src to the target, which consequently
>
>Indeed, it seems there's a bug, which causes the RepositorySidegrade to
>skip the root node properties. I think the reason lies in the
>calculateEffectiveIncludePaths() method, which produces an effective list
>of paths to migrate. If we have a '/' in the input list, the method will
>replace it with a list of '/' children and the root itself is removed
>from the list.
>
>Similar issue is present in the RepositoryUpgrade, but it isn't so
>dangerous there, as we create the root node anyway using an initializer.
>
>Created OAK-4128 to track this.
>
>However, the OAK-4128 is reproducible and present not only on the JDBC
>destination, so I guess the random failures (including the ones on
>Jenkins) are related to something else.
>
>Best regards,
>Tomek
>
>--
>Tomek Rękawek | Adobe Research | www.adobe.com
>rekawek@adobe.com
>
Re: Failing SegmentToJdbcTest.validateMigration
Posted by Tomek Rekawek <re...@adobe.com>.
Hello Angela,
> On 16 Mar 2016, at 12:39, Angela Schreiber <an...@adobe.com> wrote:
>
> stepping into the AbstractOak2OakTest and finally
> RepositorySidegrade.copyState i actually see that the target NodeBuilder
> that results from copyWorkspace doesn't have the jcr:mixinTypes
> property copied from the src to the target, which consequently
Indeed, it seems there’s a bug, which causes the RepositorySidegrade to skip the root node properties. I think the reason lies in the calculateEffectiveIncludePaths() method, which produces an effective list of paths to migrate. If we have a ‘/‘ in the input list, the method will replace it with a list of ‘/‘ children and the root itself is removed from the list.
Similar issue is present in the RepositoryUpgrade, but it isn’t so dangerous there, as we create the root node anyway using an initializer.
Created OAK-4128 to track this.
However, the OAK-4128 is reproducible and present not only on the JDBC destination, so I guess the random failures (including the ones on Jenkins) are related to something else.
Best regards,
Tomek
--
Tomek Rękawek | Adobe Research | www.adobe.com
rekawek@adobe.com