[jboss-jira] [JBoss JIRA] Commented: (JBCOMMON-119) BasicThreadPool stops using RestoreTCCLThreadPoolExecutor when setMaximumPoolSize is called

[James Livingston (JIRA)]

    [ https://issues.jboss.org/browse/JBCOMMON-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595178#comment-12595178 ] 

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