You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Julian Reschke (Jira)" <ji...@apache.org> on 2019/10/24 03:28:00 UTC
[jira] [Comment Edited] (OAK-7512) RestoreTest.testRestoreNameJcr2
occasionally failing
[ https://issues.apache.org/jira/browse/OAK-7512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16493588#comment-16493588 ]
Julian Reschke edited comment on OAK-7512 at 10/24/19 3:27 AM:
---------------------------------------------------------------
After discussingvwith [~mreutegg], we have a new theory. Test:
{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();
// 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}
Output when the test passes is like:
{noformat}
cv1date1: 1527604204311 pv1date: 1527604204311 cv1date2: 1527604204327
OK
{noformat}
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.
was (Author: reschke):
After discussingwith [~mreutegg], we have a new theory. Test:
{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();
// 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}
Output when the test passes is like:
{noformat}
cv1date1: 1527604204311 pv1date: 1527604204311 cv1date2: 1527604204327
OK
{noformat}
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
> Labels: candidate_oak_1_4
> Fix For: 1.10.0, 1.9.4, 1.8.7, 1.6.18
>
> Attachments: OAK-7512-1.patch, 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
(v8.3.4#803005)