Re: Problems with ThreadPools

[Fabian Crabus <fa...@gmail.com>]

Now, we've changed the queue size to 15.

The effect: the system runs but stutters. Looking into the queue (by
examining the SedaQueues) we find both active and
done exchanges in the queue. Once 15 is reached new threads are created and
the queue is emptied.
So far so good.

The problem is: the number of threads doesn't shrink. There are lots of
"zombie threads" that simply won't die.

Two questions remain:
- why can it be that "done" exchanges as the first item of the queue can
block the system?
- why aren't threads killed?

Fabian

On Wed, Nov 26, 2008 at 15:28, Fabian Crabus <fa...@gmail.com>wrote:

> Yes, that would work. Good idea.
> Nevertheless I still don't understand why threads could be hanging in put()
> although there's enough room left.
> But then first of all it has to work. Then I'll try to understand why ;)
>
>
> On Wed, Nov 26, 2008 at 14:15, Freeman Fang <fr...@gmail.com>wrote:
>
>> If the endpoint you see have the thread problem play the role as provider,
>> I think one solution is that you can also add thread pool on consumer side
>> so that you can control the concurrent invocation number arrive the provider
>> to avoid the resource run out problem as you said.
>>
>> For example, the work flow looks like
>> external client ===> cxf bc consumer ===> your SE
>> Although you can't control how many concurrent invocation  comes to cxf bc
>> consumer, but you can configure the cxf bc consumer thread pool size (by
>> configure the underlying jetty)to determine how many invocation can dispatch
>> to your SE at the same time.
>> This is just a example, hopefully  you can get roughly idea how things can
>> work.
>>
>> Freeman
>>
>
>