Jedis blocking connection pool vs Lettuce non‑blocking client: trade‑off for burst traffic with a fixed max‑total limit

Comparing Latency and Stability Under Burst Load

For predictable latency during burst traffic with a fixed connection limit, Lettuce is the superior choice. Because Lettuce is non-blocking and multiplexes requests over a single connection (via Netty), it avoids the "thread-per-connection" bottleneck inherent to Jedis.

Latency and Throughput Trade-offs

The primary difference lies in how each library handles a request when the max-total limit is reached:

• Jedis (Blocking): When the pool is exhausted and blockWhenExhausted=true, application threads enter a waiting state. This creates a linear increase in p99 latency as requests queue for a connection. If the burst exceeds the timeout, you will see JedisConnectionException (Could not get a resource from the pool).
• Lettuce (Non-blocking): Lettuce uses a single shared connection for most operations. A "fixed limit" in Lettuce typically refers to the number of connections in a pool used for blocking operations or transactions. For standard commands, Lettuce pipelines requests, meaning a burst of traffic does not block application threads, resulting in more stable latency profiles.

Connection Eviction and Leak Risks

Connection leaks typically occur when a resource is borrowed but not returned to the pool.

Client	Eviction Mechanism	Leak Risk Profile
Jedis	Relies on GenericObjectPoolConfig (e.g., timeBetweenEvictionRunsMillis).	High if close() is not called in a finally block.
Lettuce	Managed by Netty's event loop and internal connection state.	Low for shared connections; moderate for dedicated connection pools.

Dynamic Resizing and Scalability

The lack of runtime pool resizing in Jedis 2.x is a significant drawback for elastic workloads. If your traffic patterns shift and you need to increase max-total, a restart is required. While Lettuce also requires a new client instance for certain configuration changes, its ability to handle high concurrency with a single connection often makes the need for dynamic resizing irrelevant for standard Redis workloads.

Verification Steps

To verify the behavior in your specific environment, use a load-testing tool (e.g., JMeter) to exceed your max-total limit and monitor the following:

1. Application Side: Track thread states. A spike in WAITING or TIMED_WAITING threads indicates Jedis pool exhaustion.
2. Redis Side: Run INFO clients to monitor connected_clients. Jedis will show a count equal to your pool size; Lettuce will typically show a very low, stable number.

Diagnostic Detail Needed: Are you using blocking commands (like BLPOP) or Redis transactions (MULTI/EXEC)? These require dedicated connections in Lettuce, which would shift the performance profile closer to that of Jedis.