It can affect any user of java.nio, unless that user implements a rather dumb workaround involving constantly destroying and recreating the selector, which obviously creates a performance hit. As I understand it, this workaround has been introduced into Grizzly 2.0, but I don't know about other frameworks. Since this is a bug specific to specific versions of the JDK on a specific platform, my guess is that some developers would prefer not to put this workaround into their main code branches, and delegate the problem to the user. This is especially true when there are so many nio frameworks around, and they often compete for performance.
I should point out that this bug may not be easy to discover. 100% CPU does not mean that the application stops. In fact, your application will probably seem to run just fine. So, the only way to find this out is via OS or VM monitoring tools. In my case, I got a friendly email from my hosting provider asking me to stop stealing CPU cycles. :) Since Restlet users are heavy users of nio, I'm hoping someone else pipes up on the mailing list with more info... -Tal On 08/12/2009 12:33 AM, David Fogel wrote: > Hi Tal- > > Is it your opinion that this bug is likely to effect the > simpleframework connector as well? If so, yikes. > > -Dave > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382784 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382787
