Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#5,010 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@porunov ci sta già lavorando.

Dal 4/10/2026.

  • #5011 di @porunov — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
cassandra, java
Ambito
databases

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
5.9k
Fork
1.2k
Merge medio
2g 6h
PR unite (30g)
77

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di JanusGraph/janusgraph

Tutte le issue di JanusGraph/janusgraph

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.