It's hard to say if you're hitting the issue or not based on the
provided information.
We can try back-porting the fix as well as changes to force selector
spin detection.
How often is this occurring?
Thanks,
-rl
> Marc Arens <mailto:marc.arens_at_open-xchange.com>
> September 22, 2015 at 10:51
> Moin,
>
> we are seeing system outages at one deployment where one repeating
> point of the
> outages is a
>
> "Grizzly(1) SelectorRunner" daemon prio=10 tid=0x00007fec31068800
> nid=0x23e6
> runnable [0x00007fec6e3aa000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
> - locked <0x00000002c9c4e4a8> (a sun.nio.ch.Util$2)
> - locked <0x00000002ca5e08e0> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00000002c9bdc060> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
> at
> org.glassfish.grizzly.nio.DefaultSelectorHandler.select(DefaultSelectorHandler.java:112)
> at
> org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:325)
> at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:264)
> at
> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:551)
> at
> org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:531)
> at java.lang.Thread.run(Thread.java:745)
>
> which keeps a CPU busy at 100% for at least 15 seconds and probably
> even longer
> but those 15s is all our debug data covers at the moment.
>
> This is a Grizzly 2.2.x on java version "1.7.0_79", OpenJDK Runtime
> Environment
> (rhel-2.5.5.3.el6_6-x86_64 u79-b14), OpenJDK 64-Bit Server VM (build
> 24.79-b02,
> mixed mode).
>
> I found a 2.3.x related bug at
> https://java.net/jira/browse/GRIZZLY-1712 could
> it be this one we are hitting although it's 2.2.x? If yes, would it be
> possible
> to backport it to 2.2.x? Do you know about any other issues we might
> be hitting
> here?
>
> Best regards
> Marc
>
> --
> ...it was evening and it was morning and there were already two ways
> to store
> Unicode...