JDK-8180811 : Unexpected exception in the selector loop when many websocket connections
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 8u131,8u152
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux_ubuntu
  • CPU: x86_64
  • Submitted: 2017-05-22
  • Updated: 2018-03-28
  • Resolved: 2018-03-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbd_minorResolved
Related Reports
Duplicate :  
Duplicate :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Ubuntu 16.04.2 LTS

Linux api1 4.4.0-1013-aws #22-Ubuntu SMP Fri Mar 31 15:41:31 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux



EXTRA RELEVANT SYSTEM CONFIGURATION :
File limit per process:
Soft Limit           Hard Limit           Units     
100000               100000               files 

A DESCRIPTION OF THE PROBLEM :
We have WebSocket server which works normally with 1000 users but starts throwing errors when 2000 users use a server. After that, server leaks both opened files and memory.

Other used technologies: Scala Play Framework 2.4.6, Netty 3.10.6.Final.

The error seems to be related to shipped JDK code.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
There are no easy steps to reproduce issue at the moment


ERROR MESSAGES/STACK TRACES THAT OCCUR :
2017-05-16 15:18:28,149 WARN  o.j.n.c.s.n.AbstractNioSelector Unexpected exception in the selector loop.
java.lang.NullPointerException: null
	at sun.nio.ch.EPollArrayWrapper.isEventsHighKilled(EPollArrayWrapper.java:174) ~[na:1.8.0_131]
	at sun.nio.ch.EPollArrayWrapper.setUpdateEvents(EPollArrayWrapper.java:190) ~[na:1.8.0_131]
	at sun.nio.ch.EPollArrayWrapper.add(EPollArrayWrapper.java:239) ~[na:1.8.0_131]
	at sun.nio.ch.EPollSelectorImpl.implRegister(EPollSelectorImpl.java:178) ~[na:1.8.0_131]
	at sun.nio.ch.SelectorImpl.register(SelectorImpl.java:132) ~[na:1.8.0_131]
	at java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:212) ~[na:1.8.0_131]
	at org.jboss.netty.channel.socket.nio.NioWorker$RegisterTask.run(NioWorker.java:151) ~[io.netty.netty-3.10.4.Final.jar:na]
	at org.jboss.netty.channel.socket.nio.AbstractNioSelector.processTaskQueue(AbstractNioSelector.java:391) ~[io.netty.netty-3.10.4.Final.jar:na]
	at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:315) ~[io.netty.netty-3.10.4.Final.jar:na]
	at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89) [io.netty.netty-3.10.4.Final.jar:na]
	at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [io.netty.netty-3.10.4.Final.jar:na]
	at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [io.netty.netty-3.10.4.Final.jar:na]
	at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [io.netty.netty-3.10.4.Final.jar:na]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_131]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_131]
	at java.lang.Thread.run(Thread.java:748) [na:1.8.0_131]

REPRODUCIBILITY :
This bug can be reproduced always.


Comments
I'm closing this bug as we believe it's a duplicate of JDK-8168500. In addition, the epoll based Selector has been re-implemented for JDK 11 and we don't think the issue is possible with the new implementation.
28-03-2018

Looks like a duplicate but leaving it open for now.
26-05-2017

I don't see a backport issue for JDK-8168500 fixed in JDK 9b145. I wonder whether this fix should be backported to JDK 8? It looks as if it would be straightforward.
23-05-2017

It looks like it could very well be a duplicate. I am going to e-mail the external submitter to see whether they can try testing it on JDK 9.
23-05-2017

Is this a dup of JDK-8168500 ?
23-05-2017