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