[
https://issues.apache.org/jira/browse/SLING-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-3285.
-------------------------------------
Resolution: Fixed
I think we can close this issue with the current implementation. I'll create a
duplicate of this to keep the idea of a separate service
> ResourceResolver.isResourceType() creates admin session for every call with
> super type, slowing down processing
> ---------------------------------------------------------------------------------------------------------------
>
> Key: SLING-3285
> URL: https://issues.apache.org/jira/browse/SLING-3285
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.0.6
> Reporter: Alexander Klimetschek
> Assignee: Carsten Ziegeler
> Priority: Critical
> Labels: Performance
> Fix For: Resource Resolver 1.1.0
>
>
> SLING-2457 fixed the ACL issue with super type lookups, but at the cost of
> creating a new admin resource resolver for every super type lookup. If an
> inheritance chain contains multiple super types (N), a single call can
> trigger the creation of N admin sessions. Often this also happens for a
> number of resources per request, depending on the application, so you might
> end up creating many Jackrabbit JCR sessions per request. While creating a
> resource resolver / session is cheap, having too many at the same time has a
> big performance impact on the read performance due to increased concurrency
> in the JCR repository layer.
> This affects:
> * ResourceUtil.isA()
> * Resource.isResourceType()
> * ResourceResolver.isResourceType()
> * implementation in ResourceResolverImpl.isResourceType() and
> getParentResourceType() [1]
> A simple fix could be to cache a single admin resolver for the duration of
> the resource resolver containing it and reusing it for subsequent
> isResourceType() calls.
> Another improvement could also be to cache the isResourceType() lookups - if
> this is a typical short-lived request resource resolver. Within a request
> resource type hierarchies are unlikely to change and should probably be
> stable (and with Jackrabbit Oak the session won't refresh anyway). The cache
> would simply be a map of "resource type" => "is also this resource type", so
> that the super lookups don't have to be done again and again. Often an
> application might iterate over a tree of data and looking for the same
> resource type again and again, so the hit rate for the cache will be high.
> [1]
> https://svn.apache.org/viewvc/sling/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java?revision=1537136&view=markup
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
