[JBoss JIRA] Created: (JBCOMMON-119) BasicThreadPool stops using RestoreTCCLThreadPoolExecutor when setMaximumPoolSize is called
11:33 p.m.
BasicThreadPool stops using RestoreTCCLThreadPoolExecutor when setMaximumPoolSize is
called
-------------------------------------------------------------------------------------------
Key: JBCOMMON-119
URL: https://issues.jboss.org/browse/JBCOMMON-119
Project: JBoss Common
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: common-core (2.x)
Affects Versions: 2.2.18.GA
Reporter: James Livingston
JBCOMMON-41 modified BasicThreadPool to use a new class RestoreTCCLThreadPoolExecutor, so
that the classloader wasn't leaked. However only the code in the constructor was
changed, not the code in setMaximumQueueSize() which re-creates the executor.
This means that if you call setMaximumPoolSize(), it will switch back to the standard
executor and so the special code in RestoreTCCLThreadPoolExecutor will not run.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:43 p.m.
New subject: [JBoss JIRA] Updated: (JBCOMMON-119) BasicThreadPool stops using RestoreTCCLThreadPoolExecutor when setMaximumPoolSize is called
[
https://issues.jboss.org/browse/JBCOMMON-119?page=com.atlassian.jira.plug...
]
James Livingston updated JBCOMMON-119:
--------------------------------------
Description:
JBCOMMON-41 modified BasicThreadPool to use a new class RestoreTCCLThreadPoolExecutor, so
that the classloader wasn't leaked. However only the code in the constructor was
changed, not the code in setMaximumQueueSize() which re-creates the executor.
This means that if you call setMaximumQueueSize(), it will switch back to the standard
executor and so the special code in RestoreTCCLThreadPoolExecutor will not run.
was:
JBCOMMON-41 modified BasicThreadPool to use a new class RestoreTCCLThreadPoolExecutor, so
that the classloader wasn't leaked. However only the code in the constructor was
changed, not the code in setMaximumQueueSize() which re-creates the executor.
This means that if you call setMaximumPoolSize(), it will switch back to the standard
executor and so the special code in RestoreTCCLThreadPoolExecutor will not run.
BasicThreadPool stops using RestoreTCCLThreadPoolExecutor when
setMaximumPoolSize is called
-------------------------------------------------------------------------------------------
Key: JBCOMMON-119
URL: https://issues.jboss.org/browse/JBCOMMON-119
Project: JBoss Common
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: common-core (2.x)
Affects Versions: 2.2.18.GA
Reporter: James Livingston
JBCOMMON-41 modified BasicThreadPool to use a new class RestoreTCCLThreadPoolExecutor, so
that the classloader wasn't leaked. However only the code in the constructor was
changed, not the code in setMaximumQueueSize() which re-creates the executor.
This means that if you call setMaximumQueueSize(), it will switch back to the standard
executor and so the special code in RestoreTCCLThreadPoolExecutor will not run.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:47 p.m.
New subject: [JBoss JIRA] Updated: (JBCOMMON-119) BasicThreadPool stops using RestoreTCCLThreadPoolExecutor when setMaximumPoolSize is called
[
https://issues.jboss.org/browse/JBCOMMON-119?page=com.atlassian.jira.plug...
]
James Livingston updated JBCOMMON-119:
--------------------------------------
Attachment: jbcommon-119.diff
BasicThreadPool stops using RestoreTCCLThreadPoolExecutor when
setMaximumPoolSize is called
-------------------------------------------------------------------------------------------
Key: JBCOMMON-119
URL: https://issues.jboss.org/browse/JBCOMMON-119
Project: JBoss Common
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: common-core (2.x)
Affects Versions: 2.2.18.GA
Reporter: James Livingston
Attachments: jbcommon-119.diff
JBCOMMON-41 modified BasicThreadPool to use a new class RestoreTCCLThreadPoolExecutor, so
that the classloader wasn't leaked. However only the code in the constructor was
changed, not the code in setMaximumQueueSize() which re-creates the executor.
This means that if you call setMaximumQueueSize(), it will switch back to the standard
executor and so the special code in RestoreTCCLThreadPoolExecutor will not run.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:49 p.m.
New subject: [JBoss JIRA] Assigned: (JBCOMMON-119) BasicThreadPool stops using RestoreTCCLThreadPoolExecutor when setMaximumPoolSize is called
[
https://issues.jboss.org/browse/JBCOMMON-119?page=com.atlassian.jira.plug...
]
James Livingston reassigned JBCOMMON-119:
-----------------------------------------
Assignee: Brian Stansberry
BasicThreadPool stops using RestoreTCCLThreadPoolExecutor when
setMaximumPoolSize is called
-------------------------------------------------------------------------------------------
Key: JBCOMMON-119
URL: https://issues.jboss.org/browse/JBCOMMON-119
Project: JBoss Common
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: common-core (2.x)
Affects Versions: 2.2.18.GA
Reporter: James Livingston
Assignee: Brian Stansberry
Attachments: jbcommon-119.diff
JBCOMMON-41 modified BasicThreadPool to use a new class RestoreTCCLThreadPoolExecutor, so
that the classloader wasn't leaked. However only the code in the constructor was
changed, not the code in setMaximumQueueSize() which re-creates the executor.
This means that if you call setMaximumQueueSize(), it will switch back to the standard
executor and so the special code in RestoreTCCLThreadPoolExecutor will not run.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:49 p.m.
New subject: [JBoss JIRA] Commented: (JBCOMMON-119) BasicThreadPool stops using RestoreTCCLThreadPoolExecutor when setMaximumPoolSize is called
[
https://issues.jboss.org/browse/JBCOMMON-119?page=com.atlassian.jira.plug...
]
James Livingston commented on JBCOMMON-119:
-------------------------------------------
The attached patch changes setMaximumQueueSize() too.
Adding "pool.setMaximumQueueSize(10);" to
BasicThreadPoolTCCLTestCase.runClassLoaderSourceTest() should make it fail without the
patch, but it doesn't seem to. I'm trying to find out why
BasicThreadPool stops using RestoreTCCLThreadPoolExecutor when
setMaximumPoolSize is called
-------------------------------------------------------------------------------------------
Key: JBCOMMON-119
URL: https://issues.jboss.org/browse/JBCOMMON-119
Project: JBoss Common
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: common-core (2.x)
Affects Versions: 2.2.18.GA
Reporter: James Livingston
Attachments: jbcommon-119.diff
JBCOMMON-41 modified BasicThreadPool to use a new class RestoreTCCLThreadPoolExecutor, so
that the classloader wasn't leaked. However only the code in the constructor was
changed, not the code in setMaximumQueueSize() which re-creates the executor.
This means that if you call setMaximumQueueSize(), it will switch back to the standard
executor and so the special code in RestoreTCCLThreadPoolExecutor will not run.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
5006
days inactive
5006
days old
4 comments
1 participants
participants (1)
-
James Livingston (JIRA)