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