Random ConnectionErrors (104, Connection reset by peer)
See original GitHub issueVersion: redis-py: 3.2.1 redis server: 5.0.5
Platform: Debian
Description:
I have a connection to the Server that is idle for a few hours, and when I try to perform an operation, I get a redis.exceptions.ConnectionError: Error while reading from socket: (104, 'Connection reset by peer')
. This happens not always but often enough to be annoying. I can wrap it in a try-except and just reconnect and it will work, however i don’t want to wrap every command to redis like this.
Some Background: The program is getting tasks from a Queue implemented in Redis, computing for a few hours, getting the next task, and so on.
The question is, is this a bug or expected? Is there an option to prevent this? I don’t have any timeouts set on the client or server (everything is default). The current workaround would be to emulate a pre-ping, by sending a ping
wrapped in a try-except-and-reconnect-if-needed, but it’s not very pretty.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:24
- Comments:35 (11 by maintainers)
Hi, sorry I haven’t responded to this issue earlier. Upgrading to version 3.3.x should improve your experience. 3.3.x added a new option
health_check_interval
. You can use health checks like:The value of
health_check_interval
specifies the time in seconds a connection can be idle before its health needs to be checked. In the above case, if the connection is idle for more than 30 seconds, a round trip PING/PONG will be attempted just before your next command. If the PING/PONG fails, the connection will reestablished behind the scenes before your intended command is executed.We are currently testing GCP MemoryStore as a replacement for memcache.
Using GAE Python 2.7, we get random “ConnectionError: Error while reading from socket: (104, ‘Connection reset by peer’)”. Typically this error occurs after about 120 seconds of waiting for some redis command to complete (delete, set, get), so they can be hard to handle with a backoff mechanism.
We use version 3.3.8. I’ve been testing using
health_check_interval=30
and lower values than 30 (down to 2, currently). This seems to have made the errors less frequent, but they still occur often enough to be of concern.Perhaps this is a purely MemoryStore/redis server issue, however.