Anyone is more than welcome to investigate this issue.
Not sure what is happening and why. And without any source code it is even harder to reproduce.

Best regards,
Marcel

Thank for answer. I understand. Issue is hard to reproduce and even can be kind of bug of selector. Unless i founded minor fix: i put Thread.sleep(1) before selector.select() to prevent millions cycles per second. And i want to say that load goes even less than usual and latency for few additional milliseconds does not matter for me.
That really not properly fix, but good anough in my case :)
I can close this ticket, but you deside.

I would just like to say that I have run into a completely similar problem. I cannot tell what is causing it in my case at all. I also get 100% on the WebSocketServer.

So we too are seeing a rare but extended 100% cpu load.

I have not used NIO selectors but all of the examples I see remove the key from the selected keys set after iterating over each of them.

Example: http://tutorials.jenkov.com/java-nio/selectors.html
More info: https://www.oreilly.com/library/view/java-nio/0596002882/ch04.html (see example 4-1)

Perhaps this is the root of the problem?

So trying to investigate this area more and in the WebSocketServer why not just always remove the key after calling i.next()?

while ( i.hasNext() ) {
key = i.next();
i.remove(); // NEW LINE - you want to always remove the key from the set via iterator
...

Eliminate passing the iterator into doAccept() and doRead() which are calling "i.remove()"

and notice the there is no "i.remove()" in the key.isWritable() case. Might that be the problem that is is stuck isWritable()?

If we learn more, I will add info here.

This error happens every night. While researching, I saw that it is from websocket. When I stop the websocket, the cpu returns to normal. i found the problem today i will download the source code and examine it

The problem is gone for me on java 16.

my problem started with ssl. If no data is received without establishing a connection at the SSL destination

Anyone is more than welcome to investigate this issue. Not sure what is happening and why. And without any source code it is even harder to reproduce.

Best regards, Marcel

Dear Marcel

I'm facing same cpu overload on Selector.select in WebSocketServer class run. Maybe it happens after network failure.
I found blog that there was same overload issue in Mina lib caused by JVM bug and how to avoid it.
Below is the link about Mina's workaround, doing re-register select. It 's in korean, but you can see and understand codes.

Can you check this blog?

https://knight76.tistory.com/entry/Apache-Mina-%EC%82%AC%EB%A1%80%EC%97%90%EC%84%9C-%EB%B3%B8-Selectorselect-%EC%9D%B4%EC%8A%88-cpu-100-%ED%8A%80%EB%8A%94-%ED%98%84%EC%83%81

Best regards, JungGi

@sahnjeok feel free to open a PR

@sahnjeok feel free to open a PR

What do you mean 'PR' ? ^^;;

Pull request

Pull request

Dear Marcel

I found that sometimes selected keys iterator does not remove key.
In my cases after network issue this cpu overload happened.
Maybe there is some keys remains forever in selected keys after network problem.

I think it should always be removed after .next() function.

Best regards, JungGi

This issue made SSL unusuable in production due to freezing the server randomly multiple times per day and not being able to recover by itself.

I tried a bunch of the fixes suggested, but in the end, the solution that worked was just to use Stunnel.

• http://blog.heidt.biz/blog/2012/07/19/ssl-websocket-proxy-with-stunnel-howto/
• https://stackoverflow.com/a/25852768
• https://blog.inf.re/stunnel-transparent-proxy-to-localhost.html