Hey Jeanfrancois, have you been able to create a patch for this? Is anything
I can help with?
Thanks,
Rodrigo
Jeanfrancois Arcand-2 wrote:
>
> 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
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
>
--
View this message in context: http://www.nabble.com/Comet---Selector-spinning---100--CPU-tp23142529p23526216.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.