[ 
https://issues.apache.org/jira/browse/OAK-11827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joerg Hoh updated OAK-11827:
----------------------------
    Affects Version/s: 1.84.0

> speedup NodeImpl.isNodeType() for negative checks
> -------------------------------------------------
>
>                 Key: OAK-11827
>                 URL: https://issues.apache.org/jira/browse/OAK-11827
>             Project: Jackrabbit Oak
>          Issue Type: Task
>          Components: jcr
>    Affects Versions: 1.84.0
>            Reporter: Joerg Hoh
>            Priority: Major
>
> 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)

Reply via email to