redis/jedis · error · JedisException

Error while checking availability

Error message

Error while checking availability

What it means

Thrown by LagAwareStrategy.doHealthCheck when any unexpected exception occurs while probing a database endpoint's availability. The health check catches the underlying exception, logs it, clears the resolved bdbId, and rethrows it wrapped in a JedisException so the health status manager can treat the endpoint as unreachable/unresolvable.

Solutions

1. Verify the configured endpoint host/port is reachable (test with redis-cli -h <host> -p <port> PING).
2. Check network connectivity: firewalls, security groups, and DNS resolution for the endpoint host.
3. Inspect the logged cause ('Error while checking database availability') to identify the root exception.
4. If transient, rely on the health status manager's retry/failover to another healthy database instead of failing fast.

Example fix

// before: health check hits a dead endpoint and surfaces raw failure
LagAwareStrategy.Config cfg = LagAwareStrategy.Config.builder(endpoint, credsSupplier).build();

// after: ensure endpoint is valid and strategy failure is handled by failover
MultiDbConfig cfg = MultiDbConfig.builder(endpoint)
    .connectionPoolConfig(poolCfg)
    .healthCheckEnabled(true)
    .build();
// handle JedisException from health checks via failover listener, not by crashing

// before running health checks, verify reachability yourself
try (Socket s = new Socket(endpoint.getHost(), endpoint.getPort())) {
  // endpoint reachable
}

try {
  strategy.doHealthCheck();
} catch (JedisException e) {
  log.warn("Health check failed for endpoint", e);
  // mark endpoint unhealthy / trigger failover
}

When it happens

Trigger: Calling LagAwareStrategy.doHealthCheck() when the underlying availability probe (connection to the endpoint or the BDB-id lookup) throws any Exception — e.g. connection failure, timeout, or DNS resolution error inside the check.

Common situations: Redis endpoint is down or unreachable from the client; network partition or firewall blocking the health-check port; wrong endpoint/host configured; transient DNS failures in containerized/Kubernetes environments.

Related errors

• Database can not be removed due to no healthy database…
• All configured databases are unhealthy. Cannot initialize…
• Timeout while waiting for health check result
• Health check timed out or failed for
• healthCheckStrategySupplier must not be null

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

Appendix: source

Thrown at src/main/java/redis/clients/jedis/mcf/LagAwareStrategy.java:89

          bdbId = bdb;
        }
      }
      if (this.config.isExtendedCheckEnabled()) {
        // Use extended check with lag validation
        if (redisRestAPI.checkBdbAvailability(bdb, true,
          this.config.getAvailabilityLagTolerance().toMillis())) {
          return HealthStatus.HEALTHY;
        }
      } else {
        // Use standard datapath validation only
        if (redisRestAPI.checkBdbAvailability(bdb, false)) {
          return HealthStatus.HEALTHY;
        }
      }
    } catch (Exception e) {
      log.error("Error while checking database availability", e);
      bdbId = null;
      throw new JedisException("Error while checking availability", e);
    }
    return HealthStatus.UNHEALTHY;
  }

  public static class Config extends HealthCheckStrategy.Config {

    public static final boolean EXTENDED_CHECK_DEFAULT = true;
    public static final Duration AVAILABILITY_LAG_TOLERANCE_DEFAULT = Duration.ofMillis(5000);

    private final Endpoint restEndpoint;
    private final Supplier<RedisCredentials> credentialsSupplier;

    // SSL configuration for HTTPS connections to Redis Enterprise REST API
    private final SslOptions sslOptions;

    // Maximum acceptable lag in milliseconds (default: 5000);
    private final Duration availability_lag_tolerance;

View on GitHub (pinned to 6dac31d4c2)