Netty は、オペレーティングシステムに応じて使用できるさまざまなトランスポートをすぐにサポートしています。 現在、サポートしているのは以下のとおりです。

• NIOトランスポート - Javaをサポートするあらゆるプラットフォーム/OSで動作します
• ネイティブEpollトランスポート - Linuxのみで動作し、使用するカーネル/GLIBCのバージョンに応じて、さまざまな機能が利用可能です
• ネイティブKqueueトランスポート - 理論的にはあらゆるBSDで動作しますが、主にMacOSでテストされています。

ほとんどの企業が本番システム用のメインOSとしてLinuxを使用しているため、「ネイティブEpollトランスポート」が通常使用されているのも不思議ではありません。 このトランスポートは、汎用NIOトランスポートよりもさまざまな利点がありますが、NIOトランスポートと共有する1つの問題があります。それは、すべてのネットワーク操作のためにシステム/カーネルと通信するためにシステムコールを使用しているということです。

これには、以下が含まれます（ただし、これらに限定されません）。

• ソケットを開く
• ソケットを受け入れる
• ソケットに書き込む
• ソケットから読み取る
• ソケットを閉じる

システムコールはここ数年非常に役に立ってきましたが、システムコールは（スペクターとメルトダウンのために、将来さらにコストがかかる可能性が高い）ため、システムコールを減らすことに関心が集まっています。

非常に有望な方法の1つがio_uring（https://kernel.dk/io_uring.pdf）[1, 2]です。 これは、ほとんどの場合、すべてのシステムコールの必要性を排除するIO操作のためにカーネルと通信できる抽象化とAPIを提供します。 io_uringの正確な内部動作を説明することは範囲外ですが、最も重要な詳細は、ユーザースペースとカーネルスペースにマッピングされたメモリを使用するリングバッファーを介して通信する方法を提供することです。

Nettyが将来io_uringを利用できるようにするには、提供されたAPIを利用する新しいトランスポートを作成する必要があります。 これはC APIを使用するため、(ネイティブEpollトランスポートのように) JNI経由で行う必要があります。

• JavaおよびCプログラミング言語の経験（Javaコードからの使用方法== JNIを含む）
• LinuxとそのネットワークAPIの理解

• 難しい

• Francesco Nigro
• Norman Maurer

• https://kernel.dk/io_uring.pdf
• https://github.com/axboe/liburing

Nettyには現在、PR検証の一部として、また夜間にも実行されるユニットテストと統合テストが混在しています。 これは、機能面での回帰を追加しなかったことを確認するのに役立ちましたが、以下のような他のタイプの回帰をキャッチするのには役立ちません。

• メモリリーク（ネイティブおよび非ネイティブ）
• メモリオーバーヘッド
• 割り当ての増加
• GC圧力

これらのタイプの問題を検出するために、上記の場合に回帰しないようにするためのテスト/ツールを含むように、現在のテストスイートを強化したいと思います。

• CIビルドの一部としてテストスイートを実行し、回帰が検出された場合はビルドを失敗させることができる
• 割り当て/メモリ使用量などに関連する傾向を示すグラフを生成する

• Javaに詳しい
• テストフレームワークに詳しい
• Dockerに詳しい

• Francesco Nigro
• Norman Maurer

• 中程度

• https://github.com/CodingFabian/allocation-tracker
• https://github.com/jvm-profiling-tools/async-profiler
• https://github.com/mariusae/heapster

Nettyにはさまざまなイベントループタイプの実装が付属していますが、それらは可観測性に欠けています。外部オブザーバーがそれらの使用方法を理解できるように、カウンターとメトリクスを提供することで、ユーザーがアプリケーションのパフォーマンスボトルネックや、ターゲット負荷を達成するための構成ミスを調整および認識するのに役立ちます。可観測性はしばしば代償を伴いますが、理想的にはその影響はそれ自体で測定可能であり、可能な限り軽量になるように慎重に設計および実装する必要があります。

さまざまなユースケースで提案されたメトリクスの有効性と、テレメトリーを使用しない場合と比較した場合の影響を設計、実装、およびベンチマークします。

• Javaとベンチマークの経験
• [待ち行列理論の理解]

• 中程度

• Francesco Nigro
• Norman Maurer

Netty は、オペレーティングシステムに応じて使用できるさまざまなトランスポートをすぐにサポートしています。 現在、サポートしているのは以下のとおりです。

• NIOトランスポート - Javaをサポートするあらゆるプラットフォーム/OSで動作します
• ネイティブEpollトランスポート - Linuxのみで動作し、使用するカーネル/GLIBCのバージョンに応じて、さまざまな機能が利用可能です
• ネイティブKqueueトランスポート - 理論的にはあらゆるBSDで動作しますが、主にMacOSでテストされています。

最後の2つはNetty自体に特定のJNI実装がありますが、最初はJava NIOがほとんど変更せずに提供するものを利用しています。 実行中のシステムを監視/トラブルシューティングするのに役立つ可能性のある、このようなネイティブトランスポート実装で、特定のメトリックとテレメトリーデータを収集できます。

さまざまなユースケースで提案されたメトリクスの有効性と、テレメトリーを使用しない場合と比較した場合の影響を設計、実装、およびベンチマークします。

• Javaとベンチマークの経験
• JavaおよびCプログラミング言語の経験（Javaコードからの使用方法== JNIを含む）
• LinuxとそのネットワークAPIの理解

• 中程度

• Francesco Nigro
• Norman Maurer