Haonan Hou created RATIS-2595:
---------------------------------
Summary: Investigate and add macOS KQueue transport support
Key: RATIS-2595
URL: https://issues.apache.org/jira/browse/RATIS-2595
Project: Ratis
Issue Type: Improvement
Components: Netty
Reporter: Haonan Hou
After investigating the macOS Netty native libraries packaged in
{{{}ratis-thirdparty{}}}, it looks like the macOS KQueue transport is currently
not used by Ratis at runtime.
{{ratis-thirdparty-misc}} packages {{netty-transport-native-kqueue}} for macOS,
but Ratis currently only selects Epoll when available and otherwise falls back
to NIO. There is no KQueue branch in {{{}NettyUtils{}}}.
Evidence:
* {{NettyUtils.newEventLoopGroup(...)}} checks {{Epoll.isAvailable()}} when
native transport is enabled.
* If Epoll is unavailable, it falls back to {{{}NioEventLoopGroup{}}}.
* {{NettyUtils.getSocketChannelClass(...)}} and {{getServerChannelClass(...)}}
only choose between Epoll and NIO channel classes.
* There is no usage of {{{}KQueueEventLoopGroup{}}},
{{{}KQueueSocketChannel{}}}, or {{{}KQueueServerSocketChannel{}}}.
This seems to be historical behavior rather than an intentional design
decision, since the macOS native transport libraries are already packaged in
{{{}ratis-thirdparty{}}}.
*Acceptance Criteria*
* Decide whether Ratis should support KQueue on macOS.
* If yes, add KQueue support to the Netty event loop/channel selection logic.
* Preserve existing Linux Epoll and fallback NIO behavior.
* Add/update tests for native transport selection where feasible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
