Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem 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

Đang mở
#6 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
62/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rust
Lĩnh vực
databases

Hướng nghiên cứu

Bắt đầu bằng việc xác định SessionPool::acquire và lần theo đường đi tăng trưởng của open_session cũng như đường đi replay USE của hand_out, sau đó kiểm tra mọi thay đổi của live liên quan đến state lock và thông báo Condvar. Xác minh rằng các lỗi được thử lại cho đến deadline ban đầu, các lần giảm live thông báo cho các waiter dưới lock, và việc chờ với Duration::MAX không gây tràn số; tái hiện hành vi này bằng các bài kiểm thử stress với fake-listener.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
Rust
Star
1
Fork
0
Không có pull request nào được merge trong 30 ngày

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/iotdb-client-rust

Tất cả issue của apache/iotdb-client-rust

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.