[jboss-jira] [JBoss JIRA] Updated: (JGRP-764) Thread context classloaders: add ability to set TCCL when thread is created and unset it when thread is released

[Bela Ban (JIRA)]

     [ http://jira.jboss.com/jira/browse/JGRP-764?page=all ]

Bela Ban updated JGRP-764:
--------------------------

    Description: 
This is needed to avoid a thread context classloader leak, as described in http://jira.jboss.com/jira/browse/JGRP-752.

This issue obbsoletes http://jira.jboss.com/jira/browse/JGRP-752.

[email Brian Stansberry]

This proved problematic. Problem is that Protocol exposes getThreadFactory() but not setThreadFactory. Result is my approach of getting the DefaultThreadFactory you create, wrapping it in my class and then passing it back via the setter doesn't work.  And I suspect you don't want to change an API by adding a setThreadFactory to Protocol.

Attached are a couple patches that take a different approach. Idea is your thread factories and thread pools expose an interface to allow me to register for a callback when your create a thread or return one to the pool after use. With this I don't need any setter and also don't have to keep my wrapper class in sync w/ future changes to your stuff. I just call a getter for each factory and pool, and register for  callbacks.

First one is the fundamental one and applies this concept to DefaultThreadFactory and TimerScheduler.

Second one tweaks TP to 1) have the default and oob thread pools invoke the callbacks and 2) create them in init. Creating them in init instead of as part of connect() lets my factory get the thread pools your code creates and register for callbacks before returning the channel. If I can use the pools you create there's no need to duplicate/keep in sync with your thread pool creation logic.


  was:
This is needed to avoid a thread context classloader leak, as described in http://jira.jboss.com/jira/browse/JGRP-752.

This issue obbsoletes http://jira.jboss.com/jira/browse/JGRP-752.


> Thread context classloaders: add ability to set TCCL when thread is created and unset it when thread is released
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-764
>                 URL: http://jira.jboss.com/jira/browse/JGRP-764
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6.3, 2.7
>
>         Attachments: cl-leak-may25-1.patch, cl-leak-may25-2.patch
>
>
> This is needed to avoid a thread context classloader leak, as described in http://jira.jboss.com/jira/browse/JGRP-752.
> This issue obbsoletes http://jira.jboss.com/jira/browse/JGRP-752.
> [email Brian Stansberry]
> This proved problematic. Problem is that Protocol exposes getThreadFactory() but not setThreadFactory. Result is my approach of getting the DefaultThreadFactory you create, wrapping it in my class and then passing it back via the setter doesn't work.  And I suspect you don't want to change an API by adding a setThreadFactory to Protocol.
> Attached are a couple patches that take a different approach. Idea is your thread factories and thread pools expose an interface to allow me to register for a callback when your create a thread or return one to the pool after use. With this I don't need any setter and also don't have to keep my wrapper class in sync w/ future changes to your stuff. I just call a getter for each factory and pool, and register for  callbacks.
> First one is the fundamental one and applies this concept to DefaultThreadFactory and TimerScheduler.
> Second one tweaks TP to 1) have the default and oob thread pools invoke the callbacks and 2) create them in init. Creating them in init instead of as part of connect() lets my factory get the thread pools your code creates and register for callbacks before returning the channel. If I can use the pools you create there's no need to duplicate/keep in sync with your thread pool creation logic.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira