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

Abierto
#6 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
62/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
databases

Línea de trabajo

Comienza localizando SessionPool::acquire y siguiendo la ruta de crecimiento de open_session y la ruta de replay de USE de hand_out; después, inspecciona cada mutación de live con respecto al state lock y a la notificación de Condvar. Verifica que los fallos se reintenten hasta el deadline original, que los decrementos de live notifiquen a los waiters bajo el lock y que las esperas con Duration::MAX no provoquen overflow; reproduce el comportamiento con pruebas de estrés con fake-listener.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Rust
Estrellas
1
Forks
0
Sin PR fusionados en 30 d

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/iotdb-client-rust

Todos los issues de apache/iotdb-client-rust

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.