Fix epoll bug when receiving zero-sized datagrams #12656
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a forward port of #12644.
Motivation:
Datagrams are allowed to be empty when sent over UNIX or INET sockets.
In such cases, we cannot use "received zero bytes" as a signal that no packets were received.
Modification:
When we receive a zero-sized datagram, tell the EpollRecvByteAllocatorHandle that we really received one byte, because the allocation handles use zero as an end-of-data signal.
Such signals will put the event loop to rest, which is wrong because we don't know at this point if there are more packets to process.
Use the absence of a sender-point as signal that no packets were read from recvmsg(2), and then continue to use -1 as the end-of-data signal to allocation handle.
Add a DatagramUnicastTest to verify that we can receive multiple empty datagrams in a row without the eventloop mistakenly going to sleep.
The JDK DatagramSocket and DatagramPacket do not currently support UNIX sockets, so the test catches those specific exceptions and bails out in those cases.
Result:
Robust handling of zero-sized datagrams in the epoll transport.