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