Salut,
Rodrigo Ramirez wrote:
> Hi Jeanfrancois,
>
> I tested with JDK 1.7 b55 and I didn't get the selector thread spining. So I
> think we hit the same JDK bug everybody complains about.
Thanks!!
I will push for the fix for an upcoming JDK 6 release. I'm trying to
find a workaround right now. Will keep you posted on the issue.
--Jeanfrancois
>
>
>
> Rodrigo Ramirez wrote:
>> Hi,
>>
>> We are having this high CPU issue with Comet: After few minutes or hours
>> some times, we get a 100% CPU usage for one of the server’s CPUs. The
>> situation is pretty similar to the one described at:
>> http://www.nabble.com/Comet-handler-starts-terminating-TCP-connections-with-RST--td20337445.html
>> and http://www.nabble.com/do-select-spin-on-linux-td22974389.html
>>
>> We used jconsole / jtop to find the thread using high CPU and got this:
>>
>> Name: SelectorThread-443
>> State: RUNNABLE
>> Total blocked: 327 Total waited: 0
>>
>> Stack trace:
>> sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
>> sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:184)
>> sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)
>> sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
>> - locked sun.nio.ch.Util$1_at_3c304a
>> - locked java.util.Collections$UnmodifiableSet_at_18682d0
>> - locked sun.nio.ch.EPollSelectorImpl_at_1a7f9da
>> sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
>> com.sun.enterprise.web.connector.grizzly.SelectorThread.doSelect(SelectorThread.java:1348)
>> com.sun.enterprise.web.connector.grizzly.SelectorThread.startListener(SelectorThread.java:1295)
>> - locked [Ljava.lang.Object;@104959c
>> com.sun.enterprise.web.connector.grizzly.SelectorThread.startEndpoint(SelectorThread.java:1258)
>> com.sun.enterprise.web.connector.grizzly.SelectorThread.run(SelectorThread.java:1234)
>>
>>
>> Some points to note:
>>
>> We see the issue in different environments, including:
>> - Glassfish v2 ur2 and Glassfish v2.1
>> - Ubuntu Linux 2.6.15-26-server and 2.6.27-7-server
>> - JVM 1.6.0 and 1.6.10
>>
>>
>> This is what we have tried since we upgraded to Glassfish V2:
>>
>> 1. Applied the patch grizzly-comet-selector-patch2.jar
>>
>> 2. Removed the patch, set CometContext.setExpirationDelay(-1) and used a
>> ScheduledExecutorService to expire the Comet Handlers, but even that is
>> not working.
>>
>>
>> Since all my comet implementation is encapsulated in a single class, I am
>> attaching it. May be I am doing something silly. The commented out code is
>> for my failed workaround using set CometContext.setExpirationDelay(-1) and
>> a ScheduledExecutorService to expire the Comet Handlers.
>>
>> Does any one can suggest a workaround different from using java 1.7?
>> Should the latest Grizzly help?
>>
>> Thanks :-)
>>
>> http://www.nabble.com/file/p23142529/PortalCometQueue.java
>> PortalCometQueue.java
>>
>