[jira] [Updated] (JCR-3940) Memory leak when calling RepositoryService.obtain with null workspaceName

["Oleksandr Kuzmenko (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JCR-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oleksandr Kuzmenko updated JCR-3940:
------------------------------------
    Attachment: JCR-3940.patch.txt

> Memory leak when calling RepositoryService.obtain with null workspaceName
> -------------------------------------------------------------------------
>
>                 Key: JCR-3940
>                 URL: https://issues.apache.org/jira/browse/JCR-3940
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-spi2dav
>    Affects Versions: 2.10.1, 2.11.3
>            Reporter: Oleksandr Kuzmenko
>            Priority: Trivial
>              Labels: easyfix, patch
>         Attachments: JCR-3940.patch.txt
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> The bug is located in method *org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.obtain(CredentialsWrapper credentials, String workspaceName)*
> When passing null to *workspaceName* parameter that's what happens:
> # an instance of org.apache.jackrabbit.spi2dav.SessionInfoImpl created with null workspace name (line 770)
> # HttpClient created for this sessionInfo and stored to cache with sessionInfo as a key (line 779)
> # a new sessionInfo created with effective workspace name (line 793)
> # sessionInfo with effective workspace name returned to caller
> The problem is that HttpClient created on step 2 will not be removed from cache on call to *org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.dispose(SessionInfo)* because it is linked to sessionInfo created on step 1 which is thrown away on step 3.
> The proposed solution is pretty easy - just call *removeClient(SessionInfo)* before creating new sessionInfo on step 3.
> See attached patch.



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