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
On 09/15/2011 12:03 AM, Scott Stark wrote:
Can you translate that?
If your saying pools should be consulting some thread factory(s), how
does that differ from what Jason was talking about as strategies one
could possibly use to achieve a global constraint?
On 9/14/11 1:43 PM, Carlo de Wolf wrote:
> We should actually invert the model (especially for EJB remote
> invocations).
>
> Instead of having threads blocking on pool constraints, make the pool
> leading in thread management.
>
> Carlo
>