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.
/i