So, regarding this one, I know its a little late :) but I just got time to read the thread.
If I were to broker the static resources with a servlet adapter, would that really be any different as far as NIO is concerned? I mean its still one thread per (Active) request, right?
@Jeanfrancois:
I noticed you said "because of its one-thread-per-request mode" , are there other modes?
--Richard
----- Original Message ----
From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
To: users_at_grizzly.dev.java.net
Sent: Tuesday, February 3, 2009 12:46:36 PM
Subject: Re: Is grizzly taking full advantage of nio?
Salut,
Igor Minar wrote:
>
> On Feb 3, 2009, at 8:44 AM, Jeanfrancois Arcand wrote:
>
>> Salut,
>>
>> hijacking the thread.
>>
>> Igor Minar wrote:
>>> I had a brief discussion with colleagues about thread-count setting in glassfish.
>>> I understand that this is the max number of worker threads that grizzly can use, but what surprised me was that I believed that this wasn't the max number of concurrent connections that grizzly can process (concurrently send responses to). I know that the synchronous nature of JavaEE doesn't allow grizzly to do much magic, but I expected that grizzly could break the one thread per request paradigm for static resources.
>>> Unfortunately a simple tests with grizzly-v3-prelude and thread-count 5 shows that this is not true:
>>> wget --tries=1 --limit-rate=100 http://localhost:8080/foo.txt ->> starts the download
>>> wget --tries=1 --limit-rate=100 http://localhost:8080/foo.txt ->> starts the download
>>> wget --tries=1 --limit-rate=100 http://localhost:8080/foo.txt ->> starts the download
>>> wget --tries=1 --limit-rate=100 http://localhost:8080/foo.txt ->> starts the download
>>> wget --tries=1 --limit-rate=100 http://localhost:8080/foo.txt ->> starts the download
>>> wget --tries=1 --limit-rate=100 http://localhost:8080/foo.txt ->> times out!!
>>
>> This is a bug. The client should not times out and the request must eventually be serviced. Can you file an issue here:
>>
>> https://glassfish.dev.java.net/servlets/ProjectIssues
>
> I this case the timeout was triggered by client (wget) after 30sec (default), so I don't think that this is bug in grizzly. The request was put into the queue by grizzly because of its one-thread-per-request mode. if the client waited until one of the first 5 request finished, it would have been served.
But all requests must be serviced one by one and should not hold a thread. So there is a problem with the keep-alive mechanism IMO. I will take a look as soon as I can.
A+
--Jeanfrancois
>
> /i
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
For additional commands, e-mail: users-help_at_grizzly.dev.java.net