[jboss-as7-dev] Limiting Server Thread Usage

Carlo de Wolf cdewolf at redhat.com
Fri Sep 16 04:50:11 EDT 2011


No, you would have a thread pool per resource guarded.

Jason's proposal is working to guarding the total number of threads. So 
in those proposals the total thread pool is the resource to be guarded.

So the two complement one-another.

The tricky bit would be predicting which execution paths would use 
certain resources. This can only be done if the invocation of a method 
is disconnected from the execution, like an EJB. An EJB method uses a 
predefined set of resources.

It does become tricky however once multiple resources are involved. I 
need to figure out how to deal with that.

Carlo

On 09/15/2011 10:46 PM, Scott Stark wrote:
> So effectively, there should be one thread pool and every subsystem 
> using an event model/executors to feed it?
> To Jason's point, is one queuing strategy sufficient for all subsystems?
>
> On 9/15/11 4:18 AM, Carlo de Wolf wrote:
>> If you enter a pool with a thread that can potentially block you're 
>> already too late in the game.
>>
>> During performance testing of EAP 5 one bottleneck we found was that 
>> releasing permits on a semaphore is a single threaded operation. 
>> https://issues.jboss.org/browse/JBPAPP-4805
>>
>> Suppose we had a resource pool of 10. Then it would be much better if 
>> there are just 10 threads working through that pool. They can be fed 
>> with an unfair BlockingQueue of tasks. The resource itself would not 
>> have to be guarded with a semaphore. And the unfair BlockingQueue 
>> would maximize throughput without sacrificing response time deviation.
>> (https://issues.jboss.org/browse/JBPAPP-2763)
>>
>> Carlo
>>
>



More information about the jboss-as7-dev mailing list