The BoundedAsyncPool class has a connection leak issue

[zjHe]

When using the reactiveRedisTemplate, if the request is canceled while obtaining a connection, it will result in the connection not being released

My monitor code ，activeIdle has been rising slowly without being released

            LettuceConnectionFactory factory = (LettuceConnectionFactory) redisConnectionFactory;
            Object currentProvider = getField(factory, "reactiveConnectionProvider");
            if (currentProvider == null) {
                return;
            }
            Object delegate = getField(currentProvider, "delegate");
            if (delegate == null) {
                return;
            }
            Map<Class<?>, AsyncPool<StatefulConnection<?, ?>>> asyncPools =
                    (Map<Class<?>, AsyncPool<StatefulConnection<?, ?>>>) getField(delegate, "asyncPools");

            if (asyncPools == null) {
                return;
            }

            for (Map.Entry<Class<?>, AsyncPool<StatefulConnection<?, ?>>> entry : asyncPools.entrySet()) {
                AsyncPool<StatefulConnection<?, ?>> value = entry.getValue();
                BoundedAsyncPool boundedAsyncPool = (BoundedAsyncPool) value;
                
                int idle = boundedAsyncPool.getIdle();
               
                int maxTotal = boundedAsyncPool.getMaxTotal();
                
                int totalIdle = boundedAsyncPool.getObjectCount();
              
                int activeIdle = totalIdle - idle;
                
                int creationInProgress = boundedAsyncPool.getCreationInProgress();
                log.info("monitor | activeIdle:{} | idle:{} | creation:{} | totalIdle:{} | max:{}",
                        activeIdle,
                        idle,
                        creationInProgress,
                        totalIdle,
                        maxTotal);
                return; 

            }

When executing res.complete, it may have already been canceled，There is a concurrency issue here （may be）

private void completeAcquire(CompletableFuture<T> res, T o) {
        if (res.isCancelled()) {
            this.return0(o);
        } else {
            res.complete(o);
        }
    }

My lettuce version ==> 5.3.7.RELEASE
My spring-boot-starter-data-redis-reactive ==> 2.3.7.RELEASE

[a-TODO-rov]

Thank you for the detailed report @zjHe !
I've reviewed the issue and will add it as a bug in our backlog.
Thanks for helping improve Lettuce!

[zjHe]

When a reactive command (e.g., opsForValue().get(...) ) is cancelled (via timeout , client disconnect, or StepVerifier cancellation) exactly while the connection is being acquired from the pool but hasn't completed yet, the connection is physically closed but never returned to the pool .

This causes the BoundedAsyncPool to think the connection is still "active" (present in the all set but not in idle cache), eventually leading to PoolExhaustedException even though the connections are actually closed.

Analysis

The issue lies in the LettuceReactiveRedisConnection.AsyncConnect inner class, specifically in the race condition between the doOnNext callback (connection arrival) and the close() method (cancellation cleanup).

Location: org.springframework.data.redis.connection.lettuce.LettuceReactiveRedisConnection$AsyncConnect

The Race Scenario:

1. Thread A (Subscriber) : Subscribes to getConnection() . AsyncConnect initiates a request to the pool. this.connection is currently null .
2. Thread B (Cancellation) : The subscription is cancelled. close() is triggered.
   • close() sets the state to CLOSING .
   • CRITICAL: Since this.connection is still null (not yet arrived), connectionProvider.releaseAsync(connection) is skipped . The close() method completes, assuming cleanup is done.
3. Thread A (Pool Response) : The pool finally yields a connection. The doOnNext block in the constructor is executed:

// Inside AsyncConnect constructor
this.connectionPublisher = defer.doOnNext(it -> {
    if (isClosing(this.state.get())) {
        // ISSUE HERE:
        it.closeAsync(); 
    } else {
        connection = it;
    }
})

4. The Leak :
   • The code detects the CLOSING state and calls it.closeAsync() .
   • it.closeAsync() physically closes the Lettuce connection.
   • However, connectionProvider.releaseAsync(it) is NEVER called.
   • The BoundedAsyncPool is unaware that the connection has been discarded. It remains in the pool's internal all queue (counted as a leased connection) but is physically closed and lost.

[PreAgile]

Hi, I'd like to investigate this issue.

From the current report, it looks important to separate two cases first: whether the inconsistency can
be reproduced in BoundedAsyncPool itself during cancel/late-arrival, or whether it only happens at
the caller boundary in Spring Data Redis AsyncConnect.

I’ll start by checking the existing cancel path in BoundedAsyncPool and adding a counter-consistency
test around acquire -> cancel -> late arrival before proposing a fix.