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
- Restore connectivity to the Sentinel at host:port named in the warning (ping it on 26379); the thread will reconnect automatically.
- If the Sentinel is permanently removed, restart the client with an updated sentinel set.
- Increase subscribeRetryWaitTimeMillis to reduce log spam/backoff pressure during known outages.
- Check for LB/firewall idle timeouts killing long-lived pub/sub sockets and raise their idle limits.
- 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
- Monitor Sentinel liveness; this warning flood means a Sentinel is down
- Tune subscribeRetryWaitTimeMillis for your network's outage profile
- Raise LB/firewall idle timeouts so long-lived pub/sub sockets survive
- Remove decommissioned Sentinels from the client's sentinel set
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
- All sentinels down, cannot determine where
- Cannot get master address from sentinel running @
- Lost connection to Sentinel
- Failed to create socket.
- Blocking pub/sub operations are not supported on…
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)