[
https://issues.jboss.org/browse/WFLY-238?page=com.atlassian.jira.plugin.s...
]
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