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

Bound the batch acquire count because --prefetch-count is unbounded

Đã đóng
  • Có gì không ổn?
#62 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

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

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
python, redis
Lĩnh vực
backend, distributed-systems

Hướng nghiên cứu

Start with the --prefetch-count option, the worker's queue.Queue and acquire call, then trace RedisTaskBackend.acquire through acquire.lua and the README prefetching section. Confirm how the count reaches the queue and Redis script, and use the real redis-server reproduction described in the issue. Done requires a maintainer-selected ceiling to be consistently enforced and documented.

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

Mô tả

Deferred from the task-prefetching review (crew run) rather than fixed in that branch, because choosing a ceiling is a maintainer decision.

What

count is unbounded end to end:

  • --prefetch-count accepts any int >= 1 (the only validation is the lower bound), defaulting to 4 × threads
  • it becomes queue.Queue(maxsize=count) and acquire(..., count=count) in the worker
  • RedisTaskBackend.acquire forwards it as ARGV[8], and acquire.lua pops up to that many tasks inside one atomic EVAL

Why it matters

  • one worker can lock the entire backlog under a single lease, starving every other worker until the shared deadline expires, at which point the reaper records the whole batch FAILED with no retry
  • process memory grows with the number of buffered payloads
  • the single-threaded Redis server is blocked for work proportional to count per call (one ZPOPMIN/HGET/cjson/ZADD/HSET pass per task, inside one script execution)

Reproduced against a real redis-server: one call with ARGV[8]=6 moved all six ready tasks to the running set with an identical deadline and one worker id, leaving the ready set empty.

Options

  • cap the effective count at a documented maximum (or at a new dedicated backend option)
  • clamp prefetch_count to the queue's backlog bound, if one exists
  • derive the ceiling from lease_ttl and the expected worst-case task duration, so a buffer cannot outlive its lease

Related: the buffer dwell counts against lease_ttl (the reserve happens at fetch time), so an unbounded buffer also makes false lease expiries more likely. That ceiling is documented in the branch's README section on prefetching.

Ngôn ngữ chính
Python
Star
21
Fork
2
Merge trung bình
12 giờ 38 phút
Pull request đã merge (30 ngày)
27

Chuẩn bị môi trường

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 tương tự

Thêm issue về Python

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.