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 19:33:18 UTC

[jira] [Comment Edited] (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=16041356#comment-16041356 ] 

Timothee Maret edited comment on SLING-6939 at 6/7/17 7:32 PM:
---------------------------------------------------------------

Fixed in r1797982 ({{DistributionUtils}})  & r1797988 ({{ImportingDistributionPackageProcessor}})


was (Author: marett):
Fixed in r1797982, https://github.com/apache/sling/commit/7da0325bb6e9936f24f01d13846515960f48f171

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