From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Tue, 06 Jan 2009 11:52:43 -0500

Salut,

rama wrote:
>
> Il giorno 06/gen/09, alle ore 17:35, Jeanfrancois Arcand ha scritto:
>
>> rama wrote:
>>
>>>>
>>>> thank you for filling out an issue.
>>>>
>>>> I've fixed the problem with threads.
>>>>
>>> I have check the fix, but, in this way if you specify the max thread
>>> (N) grizzly http will start with (N) threads.
>>>
>>> So actually isn't a maximum, is a set :)
>>>
>>> Also, this doesn't convince me too much, at least in my scenario.
>>>
>>> Normally when a user do a request to grizzly, it will take few ms to
>>> be calculated and dispatched.
>>>
>>> Sometimes, when a user require a transaction list, request will take
>>> a lot more (due to db query, data aggregation, xml parsing) and,
>>> obviusly, the thread
>>>
>>> that handle this request is busy.
>>>
>>> For that reason, sometimes, i need more threads to serve user
>>> request, and i am forced to start grizzly http with 50 threads.
>>>
>>> What i am meaning, if that i can specify min / max threads, normally
>>> i will user 5 threads (more than enough for normal operation) but
>>> when someone
>>>
>>> ask for a transaction list (or other slow request) if i run out of
>>> the min threads, new threads are spawned. After a while, if threads
>>> aren't used, they just will be killed.
>>>
>>
>> What you need here is a cached thread pool. Why not configuring one
>> that ship with the JDK?
>>
>
> could you please elaborate a bit more?
> i am not familiar with thread pool, so if possible, i need something to
> read :)

Take a look at:

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool()

A+

-- Jeanfrancois


>
>