@@ -284,6 +284,45 @@ specified during initialization.
284
284
>>> pool = redis.ConnectionPool(connection_class=YourConnectionClass,
285
285
your_arg='...', ...)
286
286
287
+ Connections maintain an open socket to the Redis server. Sometimes these
288
+ sockets are interrupted or disconnected for a variety of reasons. For example,
289
+ network appliances, load balancers and other services that sit between clients
290
+ and servers are often configured to kill connections that remain idle for a
291
+ given threshold.
292
+
293
+ When a connection becomes disconnected, the next command issued on that
294
+ connection will fail and redis-py will raise a ConnectionError to the caller.
295
+ This allows each application that uses redis-py to handle errors in a way
296
+ that's fitting for that specific application. However, constant error
297
+ handling can be verbose and cumbersome, especially when socket disconnections
298
+ happen frequently in many production environments.
299
+
300
+ To combat this, redis-py can issue regular health checks to assess the
301
+ liveliness of a connection just before issuing a command. Users can pass
302
+ ``health_check_interval=N `` to the Redis or ConnectionPool classes or
303
+ as a query argument within a Redis URL. The value of ``health_check_interval ``
304
+ must be an interger. A value of ``0 ``, the default, disables health checks.
305
+ Any positive integer will enable health checks. Health checks are performed
306
+ just before a command is executed if the underlying connection has been idle
307
+ for more than ``health_check_interval `` seconds. For example,
308
+ ``health_check_interval=30 `` will ensure that a health check is run on any
309
+ connection that has been idle for 30 or more seconds just before a command
310
+ is executed on that connection.
311
+
312
+ If your application is running in an environment that disconnects idle
313
+ connections after 30 seconds you should set the ``heatlh_check_interval ``
314
+ option to a value less than 30.
315
+
316
+ This option also works on any PubSub connection that is created from a
317
+ client with ``health_check_interval `` enabled. PubSub users need to ensure
318
+ that ``get_message() `` or ``listen() `` are called more frequently than
319
+ ``health_check_interval `` seconds. It is assumed that most workloads already
320
+ do this.
321
+
322
+ If your PubSub use case doesn't regularly call ``get_message() `` or
323
+ ``listen() `` frequently, you must call ``pubsub.check_health() ``
324
+ explicitly on a regularly basis.
325
+
287
326
Parsers
288
327
^^^^^^^
289
328
0 commit comments