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

Timothee Maret commented on SLING-6939:
---------------------------------------

Thanks [~wmcgaule] for your patch. It does indeed fix the leaking user session 
obtained via {{#impersonateFromService}}. 

However, it seems there is another issue in [0]. Indeed, the resource resolver 
returned is attached to a session belonging to either {{defaultAgentService}} 
sub service user or the {{subServiceName}} sub service user, but never to the 
user session.

According to SLING-5281, the user session should be used when no 
{{subServiceName}} is not configured.
I have opened SLING-6942 to track that issue.

[0] 
https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/util/impl/DistributionUtils.java#L79

> sling distribution leaks jcr sessions
> -------------------------------------
>
>                 Key: SLING-6939
>                 URL: https://issues.apache.org/jira/browse/SLING-6939
>             Project: Sling
>          Issue Type: Bug
>          Components: Content Distribution
>    Affects Versions: Content Distribution Core 0.2.6
>            Reporter: Will McGauley
>            Assignee: Timothee Maret
>            Priority: Blocker
>             Fix For: Content Distribution Core 0.2.10
>
>         Attachments: SLING_6939.patch
>
>
> The code for acquiring a ResourceResolver in sling distribution core leaks a 
> JCR Session.  In tests I was running 50,000 sessions were leaked.
> The code in DistributionUtils.getResourceResolver() creates a Session, then 
> passes it to the ResourceResolver.getServiceResolver in the map with the key 
> "user.jcr.credentials".  This means the Session passed in is ignored (the 
> correct key would have been "user.jcr.session"), and a new session is created 
> for the service user configured - resulting in a new session.  When the 
> Resource Resolver is cleaned up the associated session is not the same as the 
> abandoned session, meaning the original session (created on line number 89 of 
> DistributionUtils) is never closed.
> Please see attached patch for a possible solution which specifies the session 
> in the ResourceResolverFactory correctly.  I have tested this locally and it 
> appears to work correctly, however it does change the behaviour because a 
> different user is not used (the caller).  I did not run any automated tests.
> Also please be aware that it appears that the method "process" of the class 
> ImportingDistributionPackageProcessor appears to never close the 
> ResourceResolver acquired from the DistributionUtils.getResourceResolver() 
> utility, please have a look.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to