What causes "Error while validating pooled Jedis object." in redis/jedis?

Read the cause logged alongside this warning to identify the concrete failure (timeout vs reset vs auth).

Error while validating pooled Jedis object.

Error message

Error while validating pooled Jedis object.

What it means

JedisFactory.validateObject is the pool's pre-borrow validator for legacy Jedis objects. It checks the target server address still matches, the socket is connected, and a PING returns PONG. Any exception during these checks is caught, logged with this message, and the object is reported invalid so the pool destroys it. Like ConnectionFactory's counterpart, it is a diagnostic eviction log, not a thrown exception.

Solutions

Read the cause logged alongside this warning to identify the concrete failure (timeout vs reset vs auth).
Enable test-while-idle and eviction intervals so stale instances die quietly instead of failing validation at borrow time.
With Sentinel, ensure JedisSentinelPool handles master switch (it re-creates the pool) rather than validating stale masters.
Check Redis ACL credentials are current — auth failures inside PING path also land here.
Set sane soTimeout/connectTimeout to avoid transient-latency validation failures.

Example fix

// before
JedisPool pool = new JedisPool(new JedisPoolConfig(), host); // validation only on borrow
// after
JedisPoolConfig pc = new JedisPoolConfig();
pc.setTestWhileIdle(true);
pc.setTestOnBorrow(true);
pc.setTimeBetweenEvictionRunsMillis(30000);
JedisPool pool = new JedisPool(pc, host);

Defensive patterns

Strategy: retry

Validate before calling

try (Jedis j = new Jedis(host, port)) {
  if (!"PONG".equals(j.ping())) throw new IllegalStateException("Redis not healthy");
}

Try / catch

try { jedis.ping(); } catch (Exception e) { pool.destroy(j); /* validator already logged */ }

Prevention

Enable testWhileIdle so dead objects are culled by the evictor, not at borrow time
With Sentinel, use JedisSentinelPool so master switches recreate the pool correctly
Keep soTimeout/connectTimeout generous enough for transient latency
Sync credentials with server ACL rotations

When it happens

Trigger: PING on the checked-out-for-validation Jedis throws (connection reset, timeout, broken pipe); the underlying connection's socket is closed; the master address moved (sentinel/cluster failover) so targetHasNotChanged is computed against changed addresses and validation aborts with an error inside.

Common situations: Redis restart/failover while the JedisPool holds idle instances; idle connections reaped by firewalls/LB; Sentinel-managed master promoted elsewhere mid-validation.

Related errors

AI-assisted analysis of redis/jedis@6dac31d4c2 (2026-09-08). Data as JSON: /api/errors/b91537acf58c5bb0. Report an issue: GitHub.

Appendix: source

Thrown at src/main/java/redis/clients/jedis/JedisFactory.java:236

  @Override
  public boolean validateObject(PooledObject<Jedis> pooledJedis) {
    final Jedis jedis = pooledJedis.getObject();
    try {
      boolean targetHasNotChanged = true;
      if (jedisSocketFactory instanceof DefaultJedisSocketFactory) {
        HostAndPort targetAddress = ((DefaultJedisSocketFactory) jedisSocketFactory)
            .getHostAndPort();
        HostAndPort objectAddress = jedis.getConnection().getHostAndPort();

        targetHasNotChanged = targetAddress.getHost().equals(objectAddress.getHost())
            && targetAddress.getPort() == objectAddress.getPort();
      }

      return targetHasNotChanged && jedis.getConnection().isConnected()
          && jedis.ping().equals("PONG");
    } catch (final Exception e) {
      logger.warn("Error while validating pooled Jedis object.", e);
      return false;
    }
  }
}

View on GitHub (pinned to 6dac31d4c2)