[jboss-as7-dev] Limiting Server Thread Usage

[Scott Marlow]

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
>
>