Joerg Hoh created OAK-11827:
-------------------------------
Summary: speedup NodeImpl.isNodeType()
Key: OAK-11827
URL: https://issues.apache.org/jira/browse/OAK-11827
Project: Jackrabbit Oak
Issue Type: Task
Components: jcr
Reporter: Joerg Hoh
We have code which iterates recursively down a Node tree, and it decides to
iterate a specific child and its children by checking its nodetype. If that
childnode does *not* have that specific nodetype, it's iterated.
When checking such a situation, we have frequently stacktraces like this:
{noformat}
at
org.apache.jackrabbit.oak.jcr.security.AccessManager.hasPermissions(AccessManager.java:54)
at
org.apache.jackrabbit.oak.jcr.session.NodeImpl.canReadMixinTypes(NodeImpl.java:1346)
at
org.apache.jackrabbit.oak.jcr.session.NodeImpl.getMixinTypeNames(NodeImpl.java:1328)
at
org.apache.jackrabbit.oak.jcr.session.NodeImpl$24.lambda$perform$0(NodeImpl.java:958)
at
org.apache.jackrabbit.oak.jcr.session.NodeImpl$24$$Lambda$1777/0x0000001801d10440.get(Unknown
Source)
at
org.apache.jackrabbit.oak.plugins.nodetype.ReadOnlyNodeTypeManager.isNodeType(ReadOnlyNodeTypeManager.java:297)
at
org.apache.jackrabbit.oak.jcr.session.NodeImpl$24.perform(NodeImpl.java:958)
at
org.apache.jackrabbit.oak.jcr.session.NodeImpl$24.perform(NodeImpl.java:953)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:230)
at
org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:113)
at
org.apache.jackrabbit.oak.jcr.session.NodeImpl.isNodeType(NodeImpl.java:953)
{noformat}
That means that despite the optimizations done in OAK-10639, we need to
consistently resolve all the mixins to be sure to return "false".
(It is not possible to rewrite that code to perform a positive check, which
would benefit then from the optimization in OAK-10639.)
I see at least 1 way to optimize this, because NodeImpl.canReadMixinTypes
performs always the same check on the same Mixin-Tree, irrespective of the
actual NodeImpl instance it is invoked on. For that the result of the
AccessManager.hasPermission call could be cached on a session level (and
invalidated on {{Session.refresh()}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
