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