Salut,
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?
>
> i can also start a thread for each request, suspend the request, and
> issue a resume when request is complete, but the overhead to spawn a new
> thread will be higher
> than using 50 worker threads.
>
> That's just my idea on this :)
>
>
>> Also I've commited some fix for async. write [1]. Please try it out,
>> if this will fix your issue.
>>
>
> tnx for the fix, i will check it asap :)
Thanks both of you!
-- Jeanfrancois
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>