Igor Minar wrote:
>
> 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?
Yes I really want to make sure at least we look at it, and without issue
I bet we will forget :-) :-)
Thanks!!!
-- 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
>