What about if we had 1 underlying thread pool that provides all the threads, and then
subsystems use a custom executor that provides a 'view' of this underlying thread
pool.
So for instance we have the main thread pool that has a max of 25 threads, we could then
give the EJB remote invocation pool is then given an executor that can use a maximum of 10
threads from the pool.
This would also allow you to give these executors a priority, so for example you could
give the web subsystem thread pool a higher priority to make sure that web requests always
get handled first.
I'm not really sure how well this would work, but I just thought I would put it out
there.
Stuart
On 15/09/2011, at 3:53 AM, Jason T. Greene wrote:
Moving to a new thread.
The big problem we run into with this is that almost every application
of a thread pool that we have needs to be highly tailored to its usage
to get the most optimal performance. So we end up with quite a few
different pools and it becomes difficult to impose a server wide limit.
There however some potential strategies we could take. Although I am
unsure as to how the overall effectiveness would be:
1. Sharing idle threads between pools
2. Force everything to go through a special blocking thread factory via
instrumentation of java.lang.Thread. Any attempt to allocate over the
max would lead to thread reclamation attempts and finally blocking until
a timeout is reached.
3. Some kind of auto-tuning weighting model. If the max total threads is
N, force all thread pools to use a percentage of N, potentially based on
establishing current config value divided by combined total.
One thing I wonder though is if cloud providers are "barking up the
wrong tree"? It seems a better limitation of an application is raw CPU
clock time and max memory usage. How they split that time into threads
doesn't really affect the scalability of the physical server, it's all
virtual process performance (who cares if someone wastes time context
switching?).
On 9/14/11 10:39 AM, Scott Stark wrote:
> The other big cross cutting concern is controlling the total number of
> threads in use by the application server. When running under a
> constrained environment that uses something like pam_limits module to
> control how many process(==java threads) a user can have, it is
> difficult to know what the server max thread usage is right now.
>
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev