[
https://issues.apache.org/jira/browse/OAK-7512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16493634#comment-16493634
]
Julian Reschke edited comment on OAK-7512 at 5/29/18 4:24 PM:
--------------------------------------------------------------
And, indeed, tuning the test case like this:
{noformat}
public void testRestoreNameJcr2() throws RepositoryException,
NotExecutableException {
// V1.0 of versionableNode has no child
Node child1 = versionableNode.addNode(nodeName4);
ensureMixinType(child1, mixVersionable);
versionableNode.getSession().save();
// create v1.0 of child
Version v1Child1 = versionManager.checkin(child1.getPath());
long cv1date1 = v1Child1.getProperty("jcr:created").getLong();
while (cv1date1 == System.currentTimeMillis()) {
// wait
}
// 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
versionManager.checkout(child1.getPath());
Version v1Child2 = versionManager.checkin(child1.getPath());
long cv1date2 = v1Child2.getProperty("jcr:created").getLong();
// V2 of versionable node has child1
versionManager.checkout(versionableNode.getPath());
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());
System.err.println("OK");
// 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());
}
{noformat}
made it fail after a few tries:
{noformat}
cv1date1: 1527605145647 pv1date: 1527605145662 cv1date2: 1527605145662
{noformat}
The change being that we wait for the system clock to change before checking in
the parent node, so it's more likely not to change for the subsequent two
operations.
was (Author: reschke):
And, indeed, tuning the test case like this:
{noformat}
public void testRestoreNameJcr2() throws RepositoryException,
NotExecutableException {
// V1.0 of versionableNode has no child
Node child1 = versionableNode.addNode(nodeName4);
ensureMixinType(child1, mixVersionable);
versionableNode.getSession().save();
// create v1.0 of child
Version v1Child1 = versionManager.checkin(child1.getPath());
long cv1date1 = v1Child1.getProperty("jcr:created").getLong();
while (cv1date1 == System.currentTimeMillis()) {
// wait
}
// 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
versionManager.checkout(child1.getPath());
Version v1Child2 = versionManager.checkin(child1.getPath());
long cv1date2 = v1Child2.getProperty("jcr:created").getLong();
// V2 of versionable node has child1
versionManager.checkout(versionableNode.getPath());
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());
System.err.println("OK");
// 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());
}
{noformat}
made it fail after a few tries:
{noformat}
cv1date1: 1527605145647 pv1date: 1527605145662 cv1date2: 1527605145662
{noformat}
The change being that we wait for the system clock to change before checking in
the parent node, so it's more likely not t change for the subsequent two
operations.
> 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
> Attachments: OAK-7512.diff
>
>
> 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
(v7.6.3#76005)
