NPE SocketChannelIOHelper.read() channel is null [WSS]

[ophibox]

I randomly get this exception (few times a day). it totally blocks any further processing of messages and handshakes, and I have to restart the app.

java.lang.NullPointerException
        at org.java_websocket.SocketChannelIOHelper.read(SocketChannelIOHelper.java:14)
        at org.java_websocket.server.WebSocketServer.run(WebSocketServer.java:324)
        at java.lang.Thread.run(Thread.java:745)

I'm only using WSS with a signed cert, so I don't really know if it would arise without SSL.
I'll report later on that.

The function is called in WebSocketServer.run() during the socket selection loop :

if( key.isReadable() ) {
    conn = (WebSocketImpl) key.attachment();
    ByteBuffer buf = takeBuffer();
    try {
        if( SocketChannelIOHelper.read( buf, conn, conn.channel ) ) {

Trying to patch with the following is actually not helping, the server still not responding to any message or handshake any more. I'm guessing the server socket is the one affected, since it
can also happen when no client is connected.

public static boolean read( final ByteBuffer buf, WebSocketImpl ws, ByteChannel channel ) throws IOException {
    if(channel==null){
        System.out.println("channel is null");      
        ws.eot();
        return false;
    }
    ...
}

using a variation without ws.eot() is printing "channel is null" infinitely.

I'll report more asap, but if anyone has a clue?

[bluechips23]

@ophibox Although I have randomly received this error few times before (once in few weeks), now I am unable to reproduce this. Do you know if anything in particular triggers this exception or how to reproduce it?

[VentureHill]

Since changing to WSS we have started having this issue intermittently. There seems to be no correlation with user load and the occurrence of this issue.

[VentureHill]

For me It occurs when my service is port scanned. The port scan client connects and disconnects before the handshake occurs, the raised IOException (SSLSocketChannel2.java:130) somehow stops the server from listening.

I've got around it (definitely not the best way) by introducing try/catch for the IOException in the key.isAcceptable() clause of the WebSocketServer.java:319.

try {
 w.channel = wsf.wrapChannel(channel, w.key);
 i.remove();
 allocateBuffers(w);

 continue;

} catch (IOException ex) {

 if (key != null)

  key.cancel();

}

Too soon to tell if its worked long term but we are back to 400 users online and I can port scan the server without it crashing.

[becast]

I'm encountering this too with Portscans. However even with @MODLR the selector.select() just hangs and does not select new connections. Anyone any Ideas?

[marci4]

merged to project