Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta Adatta ai principianti
  • Qualcosa non va?
#333 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@ali-jawad ci sta già lavorando.

Dal 23/10/2026.

  • #334 di @ali-jawad — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
77/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
backend

Direzione di ricerca

Leggi i metodi citati in AbstractClient.java per le operazioni di accodamento in batch e ricorrenti, poi AbstractWorker.java per la gestione degli errori del worker. Verifica come vengono acquisiti e chiusi pipeline e transazioni, e aggiungi test di regressione che effettuino più chiamate del maxTotal di un pool limitato. Il lavoro è completato quando queste chiamate restituiscono le connessioni al pool senza esaurirlo.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
629
Fork
132
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di gresrun/jesque

Tutte le issue di gresrun/jesque

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.