Salut,
Great analysis as usual!
if we set the processorTask to null for every request, we will regress
in term of performance as we will need to re-create/sync a new instance.
If DefaultProtocolFilter, we have:
> 134 if (streamAlgorithm.parse(byteBuffer)){
> 135
> 136 if (processorTask == null){
> 137 processorTask = selectorThread.getProcessorTask();
> 138 workerThread.setProcessorTask(processorTask);
> 139 }
For normal processing, we set that value once and re-use it. For ARP and
Comet, we are using the c.s.g.arp.AsyncProtocolFilter, and we are doing:
> 162 if (streamAlgorithm.parse(byteBuffer)){
> 163 ProcessorTask processor = selectorThread.getProcessorTask();
> 164 configureProcessorTask(processor, ctx,
> 165 streamAlgorithm.getHandler(), inputStream);
we never get the ProcessorTask from the HttpWorkerThread. So I think
your patch fix the issue but it just a bug when readerThread > 1. I
suspect (I will take a look as I might be wrong) the AsyncProtocolFilter
is not added to the ProtocolChain because the ARP is not enabled, hence
we ends up with the DefaultProtocolFilter instead of AsyncProtocolFilter.
A+
-- Jeanfrancois
Bongjae Chang wrote:
> 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
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net