redis/jedis · warning

Lost connection to Sentinel

Error message

Lost connection to Sentinel {}:{}. Sleeping {}ms and retrying.

What it means

MasterListener subscribes to Sentinel pub/sub channels; if the subscription or its connection raises JedisException (Sentinel unreachable, connection reset, timeout) while the thread is still running, this warning is logged and the thread sleeps subscribeRetryWaitTimeMillis before retrying. The client keeps attempting indefinitely — this is the expected log when a Sentinel becomes temporarily unavailable after startup.

Solutions

  1. Restore connectivity to the Sentinel at host:port named in the warning (ping it on 26379); the thread will reconnect automatically.
  2. If the Sentinel is permanently removed, restart the client with an updated sentinel set.
  3. Increase subscribeRetryWaitTimeMillis to reduce log spam/backoff pressure during known outages.
  4. Check for LB/firewall idle timeouts killing long-lived pub/sub sockets and raise their idle limits.
  5. Monitor Sentinels themselves — 2-of-3 Sentinel loss means failover detection is degraded.

Example fix

// before
new JedisSentinelPool(master, sentinels, 2000 /* subscribeRetryWaitTimeMillis default-ish */);
// after — larger retry window for flaky links
new JedisSentinelPool(master, sentinels, poolConfig, 60000 /* subscribeRetryWaitTimeMillis */);
Defensive patterns

Strategy: retry

Validate before calling

// preflight
try (Jedis j = new Jedis(sentinelHost, sentinelPort)) {
  j.ping(); // fail deployment early if sentinel unreachable
}

Try / catch

try { jedis.subscribe(pubSub, "+switch-master"); } catch (JedisException e) { if (running.get()) { Thread.sleep(subscribeRetryWaitTimeMillis); /* loop retries */ } }

Prevention

When it happens

Trigger: In MasterListener.run: the `new Jedis(hostPort, sentinelClientConfig)` connection or `j.subscribe(...)` throws JedisException — Sentinel process down, network drop, Sentinel restarted, connection evicted by a proxy/LB idle timeout.

Common situations: Sentinel host rebooted or OOM-killed; client runs in a different DC and long-lived pub/sub connections are dropped by stateful firewalls; Sentinel port blocked after network policy change; frequent warnings flooding logs during a Sentinel outage.

Understand the failure class

Background: ECONNREFUSED and "connection refused" / "could not connect to server" errors: what they mean and how to fix them — this error's family across 44 libraries.

Related errors


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

Appendix: source

Thrown at src/main/java/redis/clients/jedis/JedisSentinelPool.java:420

                if (masterName.equals(switchMasterMsg[0])) {
                  initMaster(toHostAndPort(Arrays.asList(switchMasterMsg[3], switchMasterMsg[4])));
                } else {
                  LOG.debug(
                    "Ignoring message on +switch-master for master name {}, our master name is {}",
                    switchMasterMsg[0], masterName);
                }

              } else {
                LOG.error("Invalid message received on Sentinel {} on channel +switch-master: {}",
                    hostPort, message);
              }
            }
          }, "+switch-master");

        } catch (JedisException e) {

          if (running.get()) {
            LOG.warn("Lost connection to Sentinel {}:{}. Sleeping {}ms and retrying.", host, port, subscribeRetryWaitTimeMillis,
                    e);
            try {
              Thread.sleep(subscribeRetryWaitTimeMillis);
            } catch (InterruptedException e1) {
              LOG.error("Sleep interrupted: ", e1);
            }
          } else {
            LOG.debug("Unsubscribing from Sentinel at {}:{}", host, port);
          }
        } finally {
          if (j != null) {
            j.close();
          }
        }
      }
    }

    public void shutdown() {

View on GitHub (pinned to 6dac31d4c2)