套接字读线未阻塞

Question

Events are being forwarded to a client socket, which is being read by the code below. Most of the time the code works as expected. Sometimes a data packet is sent to the socket which causes the readline to unblock with a null message. From that point forward, the readline call never blocks again, causing a CPU spike. I have verified with code that the socket is not closed, the input stream has not been shutdown, isSocketClosed and isInputShutdown both return false. The ready call is just an attempt to see what's happening, the read call always returns -1. The socket is still accepting data, new valid packets come in, processed correctly, but the readline never blocks again. Any idea how why readline is behaving this way?

while (!this.isInterrupted())
{
    String message = null;
    do {
        message = reader.readLine();
        if ( message != null && message.length() > 0 ) {
            //if ( log().isDebugEnabled())
                log().info( "Got a message, raw data: " + message );
            createEvent( message );
        }
    } while ( message != null && !this.isInterrupted());

    if(!reader.ready()) {
        log().info("Bytes read: " + reader.read());
        Thread.sleep(1000);
    }
}

Answer 1

BufferedReader.readLine() returns null when the other end closes the connection.

If it is not doing this you have a particularly bug JVM. I would make sure you have the latest update.

I have verified with code that the socket is not closed, the input stream has not been shutdown, isSocketClosed and isInputShutdown both return false

This just means your end didn't close() the stream. It doesn't tell you anything about the other end of the stream.

The ready call is just an attempt to see what's happening, the read call always returns -1

This also means you have an end of stream.

Answer 2

Just a small thing, but if you have empty (not null) strings coming in on your socket, they won't fall under if ( message != null && message.length() > 0 ) .

You might wanna change it to if ( message != null ) .

The reason this happens comes from the String#length() method:

Returns the length of this string. The length is equal to the number of Unicode code units in the string. @return the length of the sequence of characters represented by this object.

Answer 3

You have a bug in your code. If readLine() returns null, it means the peer has closed the connection. You must do likewise and exit the loop. Once it has returned null, it will never block again, and it will never stop returning null.

The part of your loop that tests ready() and sleeps is literally a compete waste of time. Remove it.