Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Every CQL read result is handed to the deserialization executor before the reader wakes, even a single small page

オープン
  • 何か問題がありますか？
#5,010 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@porunov がすでに取り組んでいます。

2026年10月4日 から。

  • #5011 @porunov による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
停滞
技術スタック
cassandra, java
領域
databases

調査の方向性

Start with AsyncCQLFunction.acceptDataChunk, StaticArrayEntryList.supplyEntryList, and CQLKeyColumnValueStore.getSlice to trace how pages are deserialized and how the reader's future is completed. Check how prepared statements and result column names are handled. Done means small single-page results can be deserialized on the I/O thread with exact-sized arrays, while large or multi-page results still use the executor; column indexes are resolved once per prepared statement. Linked pull request 5011 is already open.

索引モデルが issue の本文から書いたものです。

説明

kind/performance

Every read of the CQL backend hands its result from the driver's I/O thread to the executor service of storage.cql.executor-service.*, where it is deserialized, before the reader waiting for it is woken, however small the result is.

AsyncCQLFunction.acceptDataChunk runs on the driver's I/O thread when a page of a result arrives. For every page, the first and only one included, it queues the page in a ChunkedJobDefinition and calls StaticArrayEntryList.supplyEntryList, which submits a task to the executor service; that task turns the rows into an EntryList and completes the future the reader blocks on in CQLKeyColumnValueStore.getSlice. A read therefore wakes two threads, the executor's and the reader's, where one would do, and allocates a ChunkedJobDefinition (a ConcurrentLinkedQueue, a ReentrantLock and a CompletableFuture) per query. An empty result goes through the same hand-off to complete with EMPTY_LIST. The executor service exists so that the I/O threads, which decode every response of a node, aren't held up by deserializing large results; for the small results of most OLTP reads, a vertex's properties or a short adjacency list, the hand-off costs more than the work it moves.

The deserialization itself reads each row's cells by the names of their columns (row.getByteBuffer("column1"), which the driver resolves with a case-insensitive lookup per call), wraps them in a Tuple3 and two StaticArrayBuffers per row, and grows its arrays by doubling, copying as it goes, before a final trim copy, although the number of rows of a page and the size of its cells are known.

A result which is one page of few rows can be turned into entries on the I/O thread, with one copy into arrays of the exact size, and complete the reader's future directly; larger results and results of several pages should keep going to the executor service. The rows of every result can be read by the index of their columns, resolved once from the first result of each prepared statement.

主要言語
Java
スター
5.9k
フォーク
1.2k
平均マージ
2日 6時間
マージ済み PR（30日）
77

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

JanusGraph/janusgraph のほかの issue

JanusGraph/janusgraph の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。