-
Bug
-
Resolution: Not an Issue
-
P3
-
None
-
7u131
Grizzly simulates blocking read over NIO channel using temporary selectors.
We register a SocketChannel we want to read from on the selector with OP_READ interest and waiting for the channel to become readable. The selector immediately returns value 1, meaning that there is one channel ready to be processed. The selectedKeys collection returns single key, which is the key we registered for our channel. But when we try to read from the channel - we read 0 bytes.
Relevant Grizzly code is at
com.sun.grizzly.util.Utils.readWithTemporarySelector
*************
This turned out to be a Solaris issue ("Non-blocking recv gets unexpected EAGAIN error") fixed in Sol11.3 SRU 17
We register a SocketChannel we want to read from on the selector with OP_READ interest and waiting for the channel to become readable. The selector immediately returns value 1, meaning that there is one channel ready to be processed. The selectedKeys collection returns single key, which is the key we registered for our channel. But when we try to read from the channel - we read 0 bytes.
Relevant Grizzly code is at
com.sun.grizzly.util.Utils.readWithTemporarySelector
*************
This turned out to be a Solaris issue ("Non-blocking recv gets unexpected EAGAIN error") fixed in Sol11.3 SRU 17