NIO Selector keeps triggering reads with no data

Question

I have a custom NIO server but I am seeing a behavior that I can not reproduce nor explain: the selector keeps triggering on a certain selection key with isReadable() == true but when I read from the channel, there is no data.

I have:

• triple checked that the EOS are respected in all scenarios
• built custom clients that try all kinds of funky combinations of invalid data to trigger the bug but can not trigger it myself
• looked through the apache mina code to see if they do anything special as compared to my server
• tried different versions of the JDK (8_111 and 8_121)
• triple checked that the selection key is removed from the iterator of the selected key set in a finally block that wraps around everything after iterator.next() so it should not be a ghost key

Everything turns up empty, every weird thing I try on the client side is correctly handled by the server but nonetheless approximately every four hours (you can almost set a clock to it), an IP from Russia connects to the server and triggers the bug.

At that point the selector goes into overdrive continuously triggering the channel and the read process attached to it which keeps reporting 0 bytes incoming.

So two questions:

• apart from actual data and an EOS, what else can trigger a read operation on a selector?
• if I can not find the actual problem, is it ok to simply check for x amount of subsequent read triggers that turn up with no data and conclude that I should close the socket? There are read timeouts in place but due to the CPU-intensive nature of the bug they are too long for my comfort

UPDATE:

• it is not the server socket channel triggering the reads but one of the accepted client channels, as such it can't (shouldn't?) be an incoming connection
• by default only OP_READ is registered, OP_WRITE is registered sporadically if the internal buffers still contain data but are unregistered once the data has been sent
• the read timeouts mentioned are custom timeouts, the parser will keep track of when the first data for a message comes in and if it takes too long to complete, it will trigger a read timeout

If I knew where the problem was I could provide some code of that part but the whole server is too big to paste here.

UPDATE 2

In the debug things that I have added, I print out the following state:

selectionKey.isReadable() + "/" + selectionKey.isValid() + "/" + selectionKey.channel().isOpen()

All three booleans are always true.

Answer 1

The same issue happened to me also, check if you have kept the connection opened with the client. If it is so then selection key will be triggered with isReadable() is true, even though client is not actually sending any data.

Answer 2

Impossible to answer this properly without some code, but:

apart from actual data and an EOS, what else can trigger a read operation on a selector?

If it's a ServerSocketChannel, an incoming connection.

if I can not find the actual problem, is it ok to simply check for x amount of subsequent read triggers that turn up with no data and conclude that I should close the socket?

No. Find the bug in your code.

There are read timeouts in place

There can't be read timeouts in place on non-blocking sockets, and as you're using a Selector you must be using non-blocking sockets.

but due to the CPU-intensive nature of the bug they are too long for my comfort

I don't know what this means.