On Feb 3, 2009, at 9:46 AM, Jeanfrancois Arcand wrote:
> 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.
I think that one important detail is not clear from my wget commands,
I should have included & at the end or the --background switch. all
the wget commands above were executed concurrently when the timeout
occurred for one of them.
Do you still think that the timeout is a bug?
/i