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

Pooled clients leak a connection per call: pipelines and transactions taken from UnifiedJedis are never closed

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#333 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

@ali-jawad đang làm issue này rồi.

Từ ngày 23/10/2026.

  • #334 của @ali-jawad — đang mở

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
77/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
backend

Hướng nghiên cứu

Đọc các phương thức được dẫn trong AbstractClient.java về thao tác đưa vào hàng đợi theo lô và định kỳ, sau đó đọc AbstractWorker.java về xử lý lỗi của worker. Xác nhận cách các pipeline và transaction được lấy và đóng, đồng thời bổ sung các kiểm thử hồi quy thực hiện số lời gọi nhiều hơn maxTotal của một pool có giới hạn. Hoàn thành khi các lời gọi đó trả kết nối về pool mà không làm cạn pool.

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

Mô tả

Version: jesque 3.0.0 with its jedis 7.2.1. The code is unchanged on master (e4d551d, jedis 8.0.0).

What happens

These calls each take a connection from the client's UnifiedJedis pool and never return it:

  • ClientPoolImpl.batchEnqueue(...), through a pipeline;
  • ClientPoolImpl.recurringEnqueue(...) and ClientPoolImpl.removeRecurringEnqueue(...), through a transaction;
  • WorkerPoolImpl failure handling, through a transaction, when the FailQueueStrategy returns getFailQueueMaxItems(...) > 0.

With a bounded pool, the call after maxTotal such calls fails:

redis.clients.jedis.exceptions.JedisException: Could not get a resource from the pool
Caused by: java.util.NoSuchElementException: Timeout waiting for idle object, maxWaitDuration=PT1S
	at redis.clients.jedis.util.Pool.getResource(Pool.java:42)
	...
	at redis.clients.jedis.UnifiedJedis.pipelined(UnifiedJedis.java:6001)
	at redis.clients.jedis.RedisClient.pipelined(RedisClient.java:167)
	at net.greghaines.jesque.client.AbstractClient.doBatchEnqueue(AbstractClient.java:210)

That trace is from master (jedis 8.0.0). In the worker, the exception is caught and logged at WARN, so failures silently stop being recorded. With the default pool config (unbounded, non-blocking), nothing throws. Instead, every call leaves one more connection open on Redis: 50 batch enqueues took CLIENT LIST from 2 to 51 connections.

Why

UnifiedJedis.pipelined() and UnifiedJedis.multi() create the pipeline or transaction on a connection taken from the pool, with closeConnection = true, and only their close() returns it:

https://github.com/redis/jedis/blob/26bbb8e33af4efe569d8b7d1126329e257f79e0b/src/main/java/redis/clients/jedis/UnifiedJedis.java#L5129-L5137
https://github.com/redis/jedis/blob/26bbb8e33af4efe569d8b7d1126329e257f79e0b/src/main/java/redis/clients/jedis/UnifiedJedis.java#L5150-L5158

Jesque calls sync() or exec(), but never close():

In 2.3.0 these calls ran inside PoolUtils.doWorkInPool, which returns the Jedis to the pool, so the leak is new in 3.0.0:

https://github.com/gresrun/jesque/blob/5fbb197fda8319f47f679da4d68c38c1542a9db2/src/main/java/net/greghaines/jesque/client/ClientPoolImpl.java

The non-pooled ClientImpl and WorkerImpl aren't affected: closing a pipeline or transaction of a plain Jedis leaves its connection open.

How to reproduce

  1. Create a pooled client with maxTotal = 3, blockWhenExhausted = true and maxWait = 1s: a JedisPooled on jedis 7.x, or PoolUtils.createJedisPool(config, poolConfig) on master.
  2. Pass it to a ClientPoolImpl.
  3. Call client.batchEnqueue("q", List.of(job)) four times.
  4. The 4th call fails as above, although nothing else uses the pool.

Fix

Close the pipelines and transactions with try-with-resources. AbstractPipeline and AbstractTransaction implement Closeable without a checked exception. I'll open a PR with the fix and regression tests that run more calls than a bounded pool's maxTotal.

Workaround

Subclass ClientPoolImpl, override doBatchEnqueue (and the recurring methods, if you use them), and close the pipeline or transaction there.

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

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

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

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 gresrun/jesque

Tất cả issue của gresrun/jesque

Issue tương tự

Thêm issue về Java

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.