Re: [jboss-as7-dev] Limiting Server Thread Usage

See related discussion in irc logs http://echelog.com/logs/browse/jboss-as7/1338415200 Starting around 19:59:28 and ending before AS7-4934 is mentioned. On 05/31/2012 11:58 AM, Jeff Mesnil wrote: > > On 05/31/2012 05:36 PM, Scott Marlow wrote: >> In pull request https://github.com/jbossas/jboss-as/pull/2407, Brian and >> I have been discussing whether the (soon to be async) PU service start() >> should run in a thread from a global thread pool or a private pool owned >> by the PU service. There was also the suggestion that we create a >> temporary thread for every PU service start. > > I am having the same issue while starting JMS Bridges asynchronously. > To keep things simple, I wrapped the code in a new Thread() but I am > looking to code it in a proper way. > > In the messaging subsystem, each instance of HornetQ servers have a > startup pool service to get their own pool of threads to start their > services (queues, topic, connection factory). > If I want to be consistent, I could add *another* pool service to get > threads for JMS bridges. I am not sure that's a great thing to multiply > pool services just to start other services asynchronously. > > (On the same topic, HornetQ has also its own thread pools can be tuned > depending on the messaging usage. At the moment, they are not shared > with AS7 but that something that I need to look at) > > > -- > jeff > >> >> Has there been any discussion of our general thread pooling design since >> this email discussion (on irc perhaps?) that perhaps captures what we >> want to do next (with regard to deployment/runtime thread pools that are >> currently private and share enough attributes that they could be >> combined into a global thread pool). >> >> >> On 09/14/2011 01:53 PM, 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. >>> > >>> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev