[jira] Commented: (JCR-2465) Background threads should use jackrabbit classloader as thread context classloader

["Carsten Ziegeler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCR-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799679#action_12799679 ] 

Carsten Ziegeler commented on JCR-2465:
---------------------------------------

I've attached a patch (against 2.0 branch) which solves this problem.

> Background threads should use jackrabbit classloader as thread context classloader
> ----------------------------------------------------------------------------------
>
>                 Key: JCR-2465
>                 URL: https://issues.apache.org/jira/browse/JCR-2465
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.0-beta5
>            Reporter: Carsten Ziegeler
>            Priority: Critical
>             Fix For: 2.0.0
>
>         Attachments: thread.patch
>
>
> The RepositoryImpl uses a thread executor with a default thread factory for some background threads. These threads should use the jackrabbit class loader (the classloader used for loading jackrabbit)
> as thread context classloader. Currently the classloader is used which causes a new thread to be greated.
> For example in combination with Sling the following can happen: a jsp in sling initiates a save to jackrabbit, this causes the indexing to start which is done in a background thread. A new thread is taken from the pool and the thread context class loader is set to the thread context classloader of the jsp/sling. If now Sling is undeployed, jackrabbit still holds this class loader. This creates a hugh memory leak.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.