You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Timothee Maret (JIRA)" <ji...@apache.org> on 2017/06/07 15:20:18 UTC

[jira] [Commented] (SLING-6939) sling distribution leaks jcr sessions

    [ 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)