[jboss-as7-dev] Limiting Server Thread Usage

[Brian Stansberry]

Thanks, Scott, for posting that.

https://github.com/jbossas/jboss-as/pull/2434 exposes the pool currently 
used for parallel boot tasks as a service that extension services can 
inject and use for blocking tasks during start/stop. I also tweaked a 
couple subsystems to use the pool instead of creating their own.

On IRC we discussed possibly limiting the pool to EE subsystems, but 
that would have introduced new dependencies between modules while not 
covering some potential uses. So I just went to a more generally usable 
pool.

Jeff, yes, for a later release, probably 7.3, I want to go through the 
various thread pool usages again to improve their manageability, and 
those HQ pools are ones we should look at.

On 5/31/12 5:46 PM, Scott Marlow wrote:
> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat