NIO read spin event loop spin when half closed#7801
Conversation
Motivation: AbstractNioByteChannel will detect that the remote end of the socket has been closed and propagate a user event through the pipeline. However if the user has auto read on, or calls read again, we may propagate the same user events again. If the underlying transport continuously notifies us that there is read activity this will happen in a spin loop which consumes unnecessary CPU. Modifications: - AbstractNioByteChannel's unsafe read() should check if the input side of the socket has been shutdown before processing the event. This is consistent with EPOLL and KQUEUE transports. Result: No more read spin loop in NIO when the channel is half closed.
|
@RoganDawes - can you verify this PR fixes the issue you observed with NIO? |
|
unit tests coming soon. |
|
@RoganDawes ping |
…nt with respect to user events
|
big thanks to @normanmaurer for the unit test ... sorry for the delay! |
|
|
||
| private static boolean isAllowHalfClosure(ChannelConfig config) { | ||
| return config instanceof DefaultSocketChannelConfig && | ||
| ((DefaultSocketChannelConfig) config).isAllowHalfClosure(); |
There was a problem hiding this comment.
Replace DefaultSocketChannelConfig with SocketChannelConfig. After this its ready to be merged :)
normanmaurer
left a comment
There was a problem hiding this comment.
One change... after this LGTM
|
Sorry for the delay. I'm actually not quite sure how to test if this PR solves my problem. I pulled the latest changes, but this doesn't seem to be present, not sure how to get this branch to test 😳 FWIW, I added a to one of the handlers in the channel, and the problem seems to have gone away. |
|
@RoganDawes please just pull the latest 4.1 branch... it was just merged. |
Motivation:
AbstractNioByteChannel will detect that the remote end of the socket has
been closed and propagate a user event through the pipeline. However if
the user has auto read on, or calls read again, we may propagate the
same user events again. If the underlying transport continuously
notifies us that there is read activity this will happen in a spin loop
which consumes unnecessary CPU.
Modifications:
of the socket has been shutdown before processing the event. This is
consistent with EPOLL and KQUEUE transports.
Result:
No more read spin loop in NIO when the channel is half closed.