[jira] Updated: (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:all-tabpanel ]

Carsten Ziegeler updated JCR-2465:
----------------------------------

    Attachment: thread.patch

Proposed patch to set the thread context classloader on thread creation 

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