jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-7512) RestoreTest.testRestoreNameJcr2 occasionally failing
Date Tue, 29 May 2018 14:32:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-7512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16493588#comment-16493588

Julian Reschke commented on OAK-7512:

After discussingwith [~mreutegg], we have a new theory. Test:
   public void testRestoreNameJcr2() throws RepositoryException,
            NotExecutableException {
        // V1.0 of versionableNode has no child
        Node child1 = versionableNode.addNode(nodeName4);
        ensureMixinType(child1, mixVersionable);
        // create v1.0 of child
        Version v1Child1 = versionManager.checkin(child1.getPath());
        long cv1date1 = v1Child1.getProperty("jcr:created").getLong();

        // V1 of versionable node has child1
        Node pv1 = versionManager.checkin(versionableNode.getPath());
        String pv1name = pv1.getName();
        long pv1date = pv1.getProperty("jcr:created").getLong();

        // create V1.1 of child
        Version v1Child2 = versionManager.checkin(child1.getPath());
        long cv1date2 = v1Child2.getProperty("jcr:created").getLong();

        // V2 of versionable node has child1
        String v2 = versionManager.checkin(versionableNode.getPath()).getName();

        // restore 1.0 of versionable node --> no child
        versionManager.restore(version, true);
        assertFalse("restore must remove child node.", versionableNode.hasNode(nodeName4));

        // restore V1 via name. since child was checkin first, 1.0 should be restored
        versionManager.restore(versionableNode.getPath(), pv1name, true);
        assertTrue("restore must restore child node.", versionableNode.hasNode(nodeName4));
        child1 = versionableNode.getNode(nodeName4);
        System.err.println("cv1date1: "+ cv1date1 + " pv1date: " + pv1date + " cv1date2: "
+ cv1date2);
        assertEquals("restore must restore child node version 1.0.", v1Child1.getName(), versionManager.getBaseVersion(child1.getPath()).getName());

        // JSR283 is more clear about restoring versionable OPV=VERSION nodes
        // and states that an existing one is not restored when the parent
        // is restored (see 15.7.5 Chained Versions on Restore)

        // New JSR283 version:
        // restore V2 via name. child should still be be 1.0
        versionManager.restore(versionableNode.getPath(), v2, true);
        child1 = versionableNode.getNode(nodeName4);
        assertEquals("Node.restore('foo') must not restore child node and keep version 1.0.",
v1Child1.getName(), versionManager.getBaseVersion(child1.getPath()).getName());

Output when the test passes is like:
cv1date1: 1527604204311 pv1date: 1527604204311 cv1date2: 1527604204327

That is, the created time for the 1.1 version of the child node is indeed newer than the created
time for the parent node being restored. However, due to timer resolution (in particular on
Windows) there's no guarantee that this will always be the case.

I'm currently trying to get a failure case to verify the theory.

> RestoreTest.testRestoreNameJcr2 occasionally failing
> ----------------------------------------------------
>                 Key: OAK-7512
>                 URL: https://issues.apache.org/jira/browse/OAK-7512
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: jcr
>    Affects Versions: 1.6.11, 1.9.2
>            Reporter: Julian Reschke
>            Assignee: Julian Reschke
>            Priority: Minor
> This tests occasionally fails for me:
> {noformat}
> testRestoreNameJcr2(org.apache.jackrabbit.test.api.version.RestoreTest): restore must
restore child node version 1.0. expected:<1.[0]> but was:<1.[1]>
> {noformat}
> I *suspect* it is timing related (because it seems to happen more frequently when the
system is busy).
> Last seen on 1.6 branch.

This message was sent by Atlassian JIRA

View raw message