redis/jedis · warning · JedisException
<server status code reply>
Error message
<server status code reply>
What it means
SHUTDOWN normally closes the connection before a reply arrives, so shutdown() reads the status-code reply inside a try/catch for JedisConnectionException (expected). If a reply IS obtainable, it throws JedisException carrying the server's status text (e.g. an error because the server refused to shut down). The 'message' is thus whatever Redis returned.
Solutions
- Expect JedisException on shutdown and treat any reply as informational; catch it around shutdown()
- Check the server logs to see why SHUTDOWN did not complete
- Use SHUTDOWN NOSAVE (ShutdownParams) when a failing save is blocking the shutdown
- Verify you are allowed to run SHUTDOWN on that instance (managed services often block it)
Example fix
// before
jedis.shutdown(); // throws JedisException with server reply
// after
try {
jedis.shutdown();
} catch (JedisConnectionException expected) {
// normal: server closed the connection
} catch (JedisException e) {
log.warn("SHUTDOWN returned: {}", e.getMessage());
} Defensive patterns
Strategy: try-catch
Try / catch
try {
jedis.shutdown();
} catch (JedisConnectionException expected) {
// normal: server closed the connection
} catch (JedisException e) {
log.warn("SHUTDOWN server reply: {}", e.getMessage());
} Prevention
- Treat any exception from shutdown() as expected behavior, not a client bug
- Prefer NOSAVE when persistence may be failing and data loss is acceptable
- Confirm SHUTDOWN is permitted on managed instances before relying on it
When it happens
Trigger: Calling jedis.shutdown() and the server responds with a status/error reply instead of dropping the connection — typically when the shutdown failed (e.g. save error with SHUTDOWN NOSAVE absent, or permission issues) so the connection stays open long enough for the reply to be read.
Common situations: Testing scripts that expect the connection to die immediately but Redis replies with an error and aborts shutdown; shutdown on a server configured with appendonly/save problems that refuse persistence; using shutdown against a managed service that disallows it.
Related errors
- null is not a valid argument.
- Failed to create socket.
- HashImport ' ' has been discarded
- HashImport ' ' expects values but got
- Cannot use Jedis when in Multi. Please use Transaction or…
AI-assisted analysis of redis/jedis@6dac31d4c2 (2026-09-08).
Data as JSON: /api/errors/3999418df821585f.
Report an issue: GitHub.
Appendix: source
Thrown at src/main/java/redis/clients/jedis/Jedis.java:3645
@Override
public long lastsave() {
connection.sendCommand(LASTSAVE);
return connection.getIntegerReply();
}
/**
* Synchronously save the DB on disk, then shutdown the server.
* <p>
* Stop all the clients, save the DB, then quit the server. This commands makes sure that the DB
* is switched off without the lost of any data.
* @throws JedisException with the status code reply on error. On success nothing is thrown since
* the server quits and the connection is closed.
*/
@Override
public void shutdown() throws JedisException {
connection.sendCommand(SHUTDOWN);
try {
throw new JedisException(connection.getStatusCodeReply());
} catch (JedisConnectionException jce) {
// expected
connection.setBroken();
}
}
@Override
public void shutdown(ShutdownParams shutdownParams) throws JedisException {
connection.sendCommand(new CommandArguments(SHUTDOWN).addParams(shutdownParams));
try {
throw new JedisException(connection.getStatusCodeReply());
} catch (JedisConnectionException jce) {
// expected
connection.setBroken();
}
}
@OverrideView on GitHub (pinned to 6dac31d4c2)