Hi Abey Tom,
Unfortunately, I couldn't reproduce it in both rev.3321 and rev.3333(current svn).
I used GrizzlyWebServerDeployer in order to deploy grizzly-comet-chat.war and I think you did too.
When I have reviewed your dumps, maybe it seems that FixedThreadPool have been modified for your debug code.
http://www.nabble.com/file/p24033280/stuck_threaddump.txt
http://www.nabble.com/file/p24031598/stuck_threaddump_win32_10_15_min_max_pool_size.txt
So, would you please test it again in current svn version? And if it will be reproduced, could you attach the dump again cleanly?
Thanks.
--
Bongjae Chang
----- Original Message -----
From: "Jeanfrancois Arcand" <Jeanfrancois.Arcand_at_Sun.COM>
To: <users_at_grizzly.dev.java.net>
Sent: Tuesday, June 16, 2009 12:42 AM
Subject: Re: grizzly-comet-webserver gets stuck sometime while processing request
> Salut,
>
> Abey Tom wrote:
>> Hi
>>
>> Some times my server grizzly-comet-webserver-1.9.17-SNAPSHOT gets stuck
>> while processing the request.
>>
>> Test Case Scanario:
>> The client i'm using is the sample application from the trunk, comet-chat. I
>> open a browser window(index.html) and then keep on hitting the refresh
>> button in the browser. The browser hangs(waiting for resource from server)
>> after some hits. Pls find the screenshot of browser.
>> http://www.nabble.com/file/p24033280/stuck_request.jpg stuck_request.jpg
>>
>> I i'm using the latest trunk code (1.9.17-SNAPSHOT, rev 3321). I have tested
>> on my desktop(win XP 32 bit single core) and server class machine (4 cpu,64
>> bit, linux). The chances of reproducing the issue in SERVER is MORE than in
>> my desktop.
>>
>> Please find the attached thread dump when the server is stuck.
>> http://www.nabble.com/file/p24033280/stuck_threaddump.txt
>> stuck_threaddump.txt .
>>
>> One (strange??) thing I have noticed is that if I put a sleep in as follows
>> I'm not able to reproduce this issue.
>>
>>
>> method DefaultThreadPool.execute(Runnable){
>> ....
>> if (running){
>> try {
>> Thread.sleep(5);
>> } catch {....}
>> workQueue.offer(task);
>> queueSize.incrementAndGet();
>> }
>> }
>>
>>
>> To debug I have added some sysout statements in the following parts.
>>
>> method DefaultThreadPool.execute(Runnable){
>> ....
>> if (running){
>> System.out.println("DefaultThreadPool.execute()"+" ,
>> "+System.nanoTime()+","+Thread.currentThread().getName()
>> + " , Offer , "+ task);
>> workQueue.offer(task);
>> queueSize.incrementAndGet();
>> }
>> }
>>
>> method FixedThreadPool.BasicWorker.dowork(){
>> .......
>> Runnable r = getTask();
>>
>> System.out.println("FixedThreadPool.BasicWorker.dowork()"+" ,
>> "+System.nanoTime()+","+Thread.currentThread().getName()+" , Take , "+r);
>> if (r == poison || r == null){
>> return;
>> }
>> ......
>> }
>>
>>
>> Please find the sysout messages both in the normal case(not stuck) and stuck
>> case. I have the results in csv format.
>>
>> Normal(not stuck) sysout messages :
>> http://www.nabble.com/file/p24033280/normal.csv normal.csv
>> Stuck sysout Messages : http://www.nabble.com/file/p24033280/stuck.csv
>> stuck.csv
>>
>> Here the number of invocations of the workQueue.take() and workQueue.offer()
>> in a stuck request will be less than in the case of normal request.
>>
>> Kindly Look into this.
>> Please let me know if any other details are required to reproduce this
>> issue.
>
> Thanks. I've filled:
>
> https://grizzly.dev.java.net/issues/show_bug.cgi?id=670
>
> to track the issue.
>
> A+
>
> -- jeanfrancois
>
>
>
>>
>> Thanks,
>> Abey Tom.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
>
>
