[
https://issues.apache.org/jira/browse/RATIS-2595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haonan Hou updated RATIS-2595:
------------------------------
Priority: Minor (was: Major)
> 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
> Priority: Minor
>
> 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)
