[
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