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

Offen

#6 erstellt am 25.8.2026 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 4/5
Geschätzter Aufwand: 3-5 Tage
Anfängerfreundlichkeit: 62/100

Issue-Typ: Bug
Klarheit: Größtenteils klar
Aktivitätsstatus: Aktiv
Tech-Stack: rust
Bereich: databases

Rechercherichtung

Beginne damit, SessionPool::acquire zu finden und den Wachstumspfad von open_session sowie den USE-Replay-Pfad von hand_out nachzuverfolgen; untersuche anschließend jede Mutation von live im Verhältnis zum State-Lock und zur Condvar-Benachrichtigung. Überprüfe, dass Fehler bis zur ursprünglichen Deadline erneut versucht werden, dass Dekrementierungen von live wartende Threads unter dem Lock benachrichtigen und dass Wartezeiten mit Duration::MAX ohne Überlauf funktionieren; reproduziere das Verhalten mit Fake-Listener-Stresstests.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug

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

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.
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).
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".

Vorherrschende Sprache: Rust
Sterne: 1
Forks: 0
PR-Merge-Kennzahlen: Keine gemergten PRs in 30 T.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Erste Schritte

Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
Forken Sie das Repository und arbeiten Sie in einem Branch.
Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/iotdb-client-rust

Session::open does not fail over when openSession/requestStatementId fails (only TCP-layer failover) Offen

bug

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100

apache/iotdb-client-rust#5 · Erstellt am 25.8.2026
reconnect() holds the pool slot while sleeping between attempts Offen

enhancement

Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 65/100

apache/iotdb-client-rust#10 · Erstellt am 25.8.2026
Redirect/pool: endpoint matching has no normalization, newest hint not preferred, cache TTL/entries not configurable, TableSessionPool lacks acquire_for_device Offen

enhancement

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 45/100

apache/iotdb-client-rust#9 · Erstellt am 25.8.2026
Dead sessions are reused with auto-reconnect off; frame-too-large rejection desynchronizes the connection Offen

bug

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 55/100

apache/iotdb-client-rust#8 · Erstellt am 25.8.2026
connect_timeout is applied per resolved address, not per endpoint Offen

bug

Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100

apache/iotdb-client-rust#7 · Erstellt am 25.8.2026

Alle Issues in apache/iotdb-client-rust