[jboss-jira] [JBoss JIRA] (WFLY-238) Thread pool configuration in EE subsystem

[Eduardo Martins (JIRA)]

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

Eduardo Martins commented on WFLY-238:
--------------------------------------

If you already have a look at the WFLY-239 PR, each executor is actually made of 2 executors: one TaskListenerExecutorService that extends ThreadPoolExecutor (and their scheduled version), which may (and probably should) be shared among EE components; and the ManagedExecutorServiceImpl, specific to a EE component, that delegates contextual tasks to the shared (or not) TaskListenerExecutorService.

The TaskListenerExecutorService, like its super ThreadPoolExecutor, seems to fit better the threads subsystem for management. Now if the threads subsystem go into someplace else that's not relevant, let's just say that what I propose is for TaskListenerExecutorService to be managed wherever the other thread pools are managed.

Now for ManagedExecutorServiceImpl, what I mean is that we should for now stick with just the default ones mentioned in the specs, which have recommended jndi names, and then build from that foundation with management of stuff like what TaskListenerExecutorService to delegate, definition on other than the default executors, definition of what kind of contexts to propagate, etc. I say it's not worth to go beyond the default ones now due to timing, and due to the unknown usage of this new spec, which we both know has some issues on its own.

Similar scenario for ManagedThreadFactory, but that one is still a bit feature-poor in WFLY-239, with a big TODO in the constructor there for stuff like thread group, thread names prefix, etc, which I need to copy from the ones on thread subsystem (or get that "final" removed from jboss threads impls). So for now I didn't make a 2 level design for thread factories, which means no share among components, configuration less for default ones mentioned by the spec, but ofcourse my plan is a very similar design as executors once the configuration and share options are implemented.

Wrt ContextService, that's really something for EE subsystem only, and like I mentioned before, should probably be configuration less for now. 

                
> Thread pool configuration in EE subsystem
> -----------------------------------------
>
>                 Key: WFLY-238
>                 URL: https://issues.jboss.org/browse/WFLY-238
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: EE
>            Reporter: David Lloyd
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Alpha2
>
>
> The EE subsystem should allow for thread pool configurations which are named and bound into JNDI.
> By default the binding name should probably not impinge upon standard namespaces.  A good default name would be {{java:jboss/threadpool/xxx}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira