From: Bongjae Chang <carryel_at_korea.com>
Date: Wed, 17 Jun 2009 20:45:51 +0900

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
>>
>>
>>
>>