Hi Abey,
I attached the proposed patch experimentally.
I added HttpWorkerThread#reset() for cleaning up used thread.
When I applied it, the problem never happened.
Could you apply this patch and test it again?
--
Bongjae Chang
----- Original Message -----
From: "Bongjae Chang" <carryel_at_korea.com>
To: <users_at_grizzly.dev.java.net>
Sent: Wednesday, June 17, 2009 8:45 PM
Subject: Re: grizzly-comet-webserver gets stuck sometime while processing request
> Hi,
>
> After all, I can reproduce it and I attach HttpWatch's snapshots.
>
> I found the machine which was reproduced. :)
>
> At first, I suspect DefaultThreadPool and FixedThreadPool. So I tried to change the thread pool into JDKThreadPool.
>
> But this problem kept still.
>
> As you see the attched snapshot, whenever this problem is reproduced, the http response is pushed.
>
> Here is example.
>
> In stuck.jpg,
> ---
> req: body-background.png
> res: none
>
> req: main-background.png
> res: body-background.png
>
> req: header-background.png
> res: main-background.png
> ---
>
> Maybe when request processing is very quick, it seems that concurrent problem exists about responsing the http header and body. But I am not sure.
>
> I am also curious to know how this phenomenon can happen and I will try to analyze this as well curiously.
>
> But if anybody knows the reason, please advice me.
>
> Thanks.
>
> --
> Bongjae Chang
>
>
> ----- Original Message -----
> From: "Bongjae Chang" <carryel_at_korea.com>
> To: <users_at_grizzly.dev.java.net>
> Sent: Wednesday, June 17, 2009 6:05 PM
> Subject: Re: grizzly-comet-webserver gets stuck sometime while processing request
>
>
>> Hi Abey,
>>
>> Thank you for testing it again.
>>
>> So now, maybe two issue exists.
>>
>> 1. processing request get stuck forever
>> 2. Slow request issue
>>
>> Abey wrote:
>>> One (strange??) thing I have noticed is that if I put a manual delay in
>>> processing (sleep) in as follows I'm not getting this issue.
>>
>> I understood. Thank you for useful information.
>>
>> And I am trying to reproduce your issue continually.
>>
>> Thanks!
>>
>> --
>> Bongjae Chang
>>
>>
>> ----- Original Message -----
>> From: "Abey Tom" <appu_abey_tom_at_yahoo.com>
>> To: <users_at_grizzly.dev.java.net>
>> Sent: Wednesday, June 17, 2009 5:48 PM
>> Subject: Re: grizzly-comet-webserver gets stuck sometime while processing request
>>
>>
>>>
>>> I'm facing both stuck forever request(never released) and slow request issues
>>> even when I use the default thread pool configuration (min/max - 5/5).
>>>
>>> I tested with the scenarios with
>>> 1. -Dcom.sun.grizzly.maxSelectorReadThread = 0 : The request processing is
>>> very quick but requests are getting stuck more often.
>>> 2. -Dcom.sun.grizzly.maxSelectorReadThread = 1 or 2 : The request
>>> processing is slower but some requests seems to get stuck but they are
>>> released. But STILL some requests are stuck forever.
>>>
>>> The chances of getting STUCK are MORE in Powerful server class machines(4
>>> core , 64bit, Linux) than in my laptop(Single core,32 bit , Windows ).
>>>
>>> Also abstract from first mail:
>>>
>>> One (strange??) thing I have noticed is that if I put a manual delay in
>>> processing (sleep) in as follows I'm not getting this issue.
>>>
>>>
>>> method DefaultThreadPool.execute(Runnable){
>>> ....
>>> if (running){
>>> try {
>>> Thread.sleep(2);
>>> //or Thread.sleep(5);
>>> } catch {....}
>>> workQueue.offer(task);
>>> queueSize.incrementAndGet();
>>> }
>>> }
>>>
>>>
>>> Thanks,
>>> Abey Tom
>>>
>>>
>>> BongJaeChang wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> When I tested it with various situations, I could meet some strange
>>>>> behavior.
>>>>>
>>>>> When I used the read thread count which was not 0, processing request was
>>>>> very slow. For a while, it seemed getting stuck, but it always was
>>>>> released.
>>>>>
>>>>> At first, I thought that the behavior was normal. But when I set the read
>>>>> thread count to be 0, I could know that processing request is very quick.
>>>>>
>>>>> So,
>>>>> 1. Could you please test it again with
>>>>> "-Dcom.sun.grizzly.maxSelectorReadThread=0" ?
>>>>>
>>>>> 2. And is your problem that processing request is slow or the page gets
>>>>> stuck and it is never released?
>>>>>
>>>>> It seems that it is not important the number of the read thread count if
>>>>> it is not 0 because I can always meet the symptom with setting the read
>>>>> thread count to be even 1.
>>>>>
>>>>> And the number of worker threads is not also important because it can see
>>>>> that the number has changed adequately. But it is not sure.
>>>>>
>>>>> So I am also debugging it in order to know why the page is slow when I
>>>>> set the read thread count to be even 1.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> --
>>>>> Bongjae Chang
>>>>
>>>
>>> --
>>> View this message in context: http://www.nabble.com/grizzly-comet-webserver-gets-stuck-sometime-while-processing-request-tp24033280p24069466.html
>>> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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