Fix incorrect channel factory selection for custom EventLoopGroups #4074
+404
−30
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
j-bahr
force-pushed
the
io_uring-fix
branch
6 times, most recently
from
1318feb to
e1dbd40
Compare
`LoopResources.onChannel()` and `onChannelClass()` incorrectly selected channel factories when users provided custom `EventLoopGroups` via `runOn()`. The previous logic only checked if `DefaultLoopNativeDetector.INSTANCE` (the highest-priority available transport) supported the group, falling back to `NIO` otherwise. This caused issues when, for example, `io_uring` was the default transport but a user explicitly provided an `Epoll` `EventLoopGroup` - the code would incorrectly return `NIO` channel factories instead of `Epoll` ones. Changes: - Add forGroup(EventLoopGroup) method to `DefaultLoopNativeDetector` that checks all available transports (`io_uring`, `epoll`, `kqueue`, `nio`) to find the correct channel factory for any given `EventLoopGroup` - Fix `DefaultLoopNIO.supportGroup()` to properly detect `NIO` event loops using `isCompatible(NioIoHandle.class)`, matching the pattern used by other transports - Update `onChannel()` and `onChannelClass()` to use `forGroup()` instead of the previous INSTANCE-or-NIO logic Signed-off-by: Jeff Bahr <[email protected]>
violetagg
reviewed
Jan 26, 2026
Comment on lines
+80
to
+84
| if (NIO.supportGroup(group)) { | ||
| return NIO; | ||
| } | ||
| // Fallback to NIO for unknown group types | ||
| return NIO; |
Member
There was a problem hiding this comment.
Whether NIO supports the ELG or not, we will return NIO?
Contributor
Author
There was a problem hiding this comment.
We do an exhaustive search above so the other option would be to throw an exception that no DefaultLoop was found for the given EventLoopGroup. This would only break if a new EventLoopGroup type is added in the future. What do you suggest?
Contributor
Author
|
@violetagg I had to make a number of changes to the gradle build file to get the multi release jar support to work in tests. I'm not an expert with gradle so feel free to comment or make changes if you are not happy with what I did. Thanks. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
LoopResources.onChannel()andonChannelClass()incorrectly selected channel factories when users provided customEventLoopGroupsviarunOn(). The previous logic only checked ifDefaultLoopNativeDetector.INSTANCE(the highest-priority available transport) supported the group, falling back toNIOotherwise.This caused issues when, for example,
io_uringwas the default transport but a user explicitly provided anEpollEventLoopGroup- the code would incorrectly returnNIOchannel factories instead ofEpollones.Changes:
forGroup(EventLoopGroup)method toDefaultLoopNativeDetectorthat checks all available transports (io_uring,epoll,kqueue,nio) to find the correct channel factory for any givenEventLoopGroupDefaultLoopNIO.supportGroup()to properly detectNIOevent loops usingisCompatible(NioIoHandle.class), matching the pattern used by other transportsonChannel()andonChannelClass()to useforGroup()instead of the previous INSTANCE-or-NIO logic