Hi,
>>
>> 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.
Agree. I also prefer to remove that logic.
> 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.
>
> 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 :)
I understand your idea. Previous default Pipeline thread pool
implementation Grizzly had, worked that way. But now we moved to JDK
ExecutorService. Default thread pool implementation we use now is
ThreadPoolExecutor [1], which has different logic. It starts to spawn
new Threads only if thread pool tasks queue becomes full. So it's not
exactly what you're looking for.
As solution we can think about implementing custom ExecutorService...
>> 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.
WBR,
Alexey.
[1]
http://java.sun.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>