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

SessionPool acquire: growth/hand-out failures bypass acquire_timeout budget; live counter decremented outside the state lock loses Condvar wakeups; acquire_timeout = Duration::MAX panics

Aperta
#6 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
62/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
databases

Direzione di ricerca

Inizia individuando SessionPool::acquire e seguendo il percorso di crescita di open_session e il percorso di replay di USE di hand_out; quindi esamina ogni mutazione di live rispetto allo state lock e alla notifica di Condvar. Verifica che i fallimenti vengano ritentati fino alla deadline originale, che i decrementi di live notifichino i waiters sotto il lock e che le attese con Duration::MAX non causino overflow; riproduci il comportamento con test di stress con fake-listener.

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

Descrizione

bug

Three related pool-accounting defects found by stress-testing SessionPool against fake listeners:

  1. acquire() spends none of its acquire_timeout budget when the growth branch fails. When open_session() fails, acquire() returns the error immediately (measured 198us against a 5s budget; 4136 of 4800 acquires failed instantly under stress while sessions were circulating). The same happens when the USE replay in hand_out fails — it discards the remaining idle candidates instead of retrying the loop.
  2. live is decremented outside the state lock at several sites, and the decremented value is exactly the predicate parked waiters re-evaluate, so Condvar notifications can be lost. The comment "Only mutated while holding state" no longer matches the code. Measured stalls track acquire_timeout exactly (300ms → 305ms, 1000ms → 1.005s).
  3. acquire_timeout = Duration::MAX panics on Instant::now() + acquire_timeout overflow before the lock is taken. There is no "never time out" option, and Duration::MAX is the natural way to ask for one.

Fix: on growth/hand-out failure, re-take the lock, decrement live under it, notify, and continue the loop (bounded by the original deadline); use a saturating deadline (checked_add) so Duration::MAX means "wait without timeout".

Lingua principale
Rust
Stelle
1
Fork
0
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

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 apache/iotdb-client-rust

Tutte le issue di apache/iotdb-client-rust

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.