[jira] [Commented] (SLING-11780) Cache non-existing resources

["Roy Teeuwen (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-11780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691105#comment-17691105 ] 

Roy Teeuwen commented on SLING-11780:
-------------------------------------

[~joerghoh] are you proposing to fix this on ResourceResolver level or on JcrResourceProvider level? I don't see this working if you put the cache on ResourceResolver and you'd have a ResourceProvider that takes specific cases to return / not return null for the same path, seeing as the ResourceProvider could be another one not backed by JCR so the cache purge events will not be valid there

> Cache non-existing resources
> ----------------------------
>
>                 Key: SLING-11780
>                 URL: https://issues.apache.org/jira/browse/SLING-11780
>             Project: Sling
>          Issue Type: Improvement
>          Components: ResourceResolver
>    Affects Versions: Resource Resolver 1.10.0
>            Reporter: Joerg Hoh
>            Assignee: Joerg Hoh
>            Priority: Major
>
> I found that in many situations various Sling features probe for the existence of resources, for example the Sling Servlet Resolution and also Sling Context-Aware Configuration. If these functions are called multiple times during the lifetime of a ResourceResolver, the ResourceResolver always checks for the presence of these resources and will consistently return "null" (non-existing resource).
> Due to the MVCC pattern we can cache the information that a resource does not exist at the ResourceResolver.
> To support changes performed to the Repository by this specific ResourceResolver, this cache should be purged by a modifying operations (move, copy, create, delete), but also on refresh.
> (Background: I found that for the rendering on a mildly complex AEM page (WKND sample content) I have 18 paths, for which the existence of a resource is tested more than 50 times and consistently returned "null". I expect that a caching of this information will save a good number of CPU cycles in Oak.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)