You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2010/01/13 11:10:54 UTC
[jira] Created: (JCR-2465) Background threads should use jackrabbit
classloader as thread context classloader
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
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.
[jira] Resolved: (JCR-2465) Background threads should use
jackrabbit classloader as thread context classloader
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting resolved JCR-2465.
--------------------------------
Resolution: Fixed
Fix Version/s: (was: 2.0.0)
2.0-beta6
Thanks! Patch applied in revision 898699 and merged to the 2.0 branch in revision 898702.
> 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
> Assignee: Jukka Zitting
> Priority: Critical
> Fix For: 2.0-beta6
>
> 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.
[jira] Assigned: (JCR-2465) Background threads should use
jackrabbit classloader as thread context classloader
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting reassigned JCR-2465:
----------------------------------
Assignee: Jukka Zitting
> 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
> Assignee: Jukka Zitting
> 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.
[jira] Commented: (JCR-2465) Background threads should use
jackrabbit classloader as thread context classloader
Posted by "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.
[jira] Updated: (JCR-2465) Background threads should use jackrabbit
classloader as thread context classloader
Posted by "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.