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