Salut,
Richard Corsale wrote:
> 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?
>
Right, except the write can be done on another thread.
> @Jeanfrancois:
> I noticed you said "because of its one-thread-per-request mode" , are there other modes?
See:
http://blogs.sun.com/oleksiys/entry/asynchronous_http_responses_with_grizzly
A+
-- Jeanfrancois
>
> --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
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>