users@grizzly.java.net

Re: do select spin on linux

From: Richard Corsale <igf1_at_yahoo.com>
Date: Thu, 9 Apr 2009 15:49:46 -0700 (PDT)

so do I need to build grizzly under 1.7 to fix this or just run in a JVM of V 1.7?




________________________________
From: John Franey <jjfraney_at_gmail.com>
To: users_at_grizzly.dev.java.net
Sent: Thursday, April 9, 2009 2:31:17 PM
Subject: Re: do select spin on linux

Jeanfrancois,

I got lucky, here is a test case. (gmail didn't let me send it as zip, so its a jar).

this is a maven project, I guess you can build and run.

There are two main classes.

A receiver, BReceiver, and a sender, UDPSender.

I run these from eclipse. I guess your IDE will let your run them easily, but I guess from the command line something easy like:
java -cp target/classes grizzlyproto/BReceiver would run.

BReciever cycles a single udp port through many connections. UDPSender sends datagrams to that port at high rate.

Periodically, BReceiver pauses at a time when there should be no cpu charges to that process. Not sure this helps, but the intention was that if the process is using cpu at this time, then the selector is spinning.

Within a few moment, BReceiver will get an exception (I do not know if the exception is related to the problem). Then you can set breakpoint on Controller.doSelect's return from selectorHandler.select (at line 329) to inspect value of readyKeys. Its empty.


Here are my system specificaitons (from ubuntu 8.10)
Linux isidore 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux


I get the same behavior on both of these:

java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)

and

java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
BEA JRockit(R) (build R27.5.0-110-94909-1.6.0_03-20080204-1558-linux-x86_64, compiled mode)


Regards,
John



On Thu, Apr 9, 2009 at 2:00 PM, John Franey <jjfraney_at_gmail.com> wrote:

Thanks.



On Thu, Apr 9, 2009 at 1:02 PM, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com> wrote:

Salut,


John Franey wrote:

Hi,

I'm running stress tests on linux. At some point, cpu utilization goes high. I've verified using the debugger that Controller.doSelect gets zero keys back from handler's select.


Yes this is an issue I've reported awhile ago to the JDK team. This sounds like bugparade 6403933

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933

A connection is reset causes the file descriptor to be selected with events POLLHUP and POLLERR but unless there is data waiting to be read then channel will not be selected. It's a awkward problem.

This has been fixed in JDK 7 build 50 and will be included in JDK 6u16.



The last statement in the evaluation of this bug nails it, and the load pattern described in this bug matches mine: http://bugs.sun.com/view_bug.do?bug_id=6693490

It sounds like the same root cause?





Google search led me to this page at apache mina jira DIRMINA-678 <https://issues.apache.org/jira/browse/DIRMINA-678>.

Please see especially, this comment from Emannual Lecharmy (31/Mar/09 03:23 PM) <https://issues.apache.org/jira/browse/DIRMINA-678?focusedCommentId=12696711&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12696711>.


So, I'm looking for this 'beautiful hack' in the Controller source code for 1.9.11 and am not seeing it. I think maybe I'm blind :) or the hack is in grizzly 2.0? If its in 2.0, do you think I can make it fit into 1.9.11? Or do you advise I try my application on 2.0 trunk?

I didn't put the hack there (just for Comet) as I never saw it on the Controller. Can you share a test case?


I don't have a test case and am working on one. I would be surprised if I can get it to happen without a lot of work.

Is there a code sample from comet that has this hack in it to see if I can make the same change for my app?
 


Thanks

-- Jeanfrancois




Thanks,
John




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