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

Alexander Klimetschek edited comment on SLING-5277 at 10/25/16 4:39 PM:
------------------------------------------------------------------------

AFAICS, SLING-6165 just moves this to a different place, but has the same 
problem that the admin/service resolver is created for each request (upon 
SlingRequestEvent.EventType.EVENT_INIT it does 
rrf.getServiceResourceResolver(null) in ScriptingResourceResolverFactoryImpl), 
even if it is never accessed, because nothing asks for resolving a resource 
type etc.

Note that this issue is not about admin vs. service user but about performance 
of creating this extra session, which adds cost to every single sling request, 
even if not used at all.


was (Author: alexander.klimetschek):
AFAICS, SLING-6165 just moves this to a different place, but has the same 
problem that the admin resolver is created for each request (upon 
SlingRequestEvent.EventType.EVENT_INIT it does 
rrf.getServiceResourceResolver(null) in ScriptingResourceResolverFactoryImpl), 
even if it is never accessed, because nothing asks for resolving a resource 
type etc.

> Performance: per thread script resolver (admin session) is always created 
> even if cache is hit
> ----------------------------------------------------------------------------------------------
>
>                 Key: SLING-5277
>                 URL: https://issues.apache.org/jira/browse/SLING-5277
>             Project: Sling
>          Issue Type: Bug
>          Components: Servlets
>            Reporter: Alexander Klimetschek
>         Attachments: SLING-5277-new.patch, SLING-5277.patch
>
>
> Since SLING-3441, for every request, a new admin / privileged session is 
> [created in the 
> SlingServletResolver|https://github.com/apache/sling/blob/trunk/bundles/servlets/resolver/src/main/java/org/apache/sling/servlets/resolver/internal/SlingServletResolver.java#L532].
>  It is created before the script/servlet cache is checked, so in most cases 
> when the cache is hit it is never used, but the cost of creating an extra 
> session (which can vary, especially with concurrent traffic) is incurred.
> The per thread script resolver can be created lazily instead of directly in 
> the event to avoid this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to