nchan_redis_retry_commands

The `nchan_redis_retry_commands` directive specifies the number of times Nchan will retry sending commands to the Redis server in case of failure.

Syntaxnchan_redis_retry_commands number;
Defaultnone
Contextupstream
Arguments1

Description

The nchan_redis_retry_commands directive is used in the context of the upstream configuration block in Nginx's Nchan module, which interfaces with Redis for pub/sub message distribution. This directive takes a numerical argument that defines how many times Nchan should attempt to resend commands to the Redis server if an initial command fails to deliver due to a transient error or network issue.

When communicating with Redis, transient errors may occur for a variety of reasons, including network fluctuations or momentary unavailability of the Redis service. Configuring this directive helps ensure resilience and message delivery reliability, as it allows Nchan to make multiple attempts to communicate with Redis without failing immediately. This is particularly useful in high-load environments where temporary network issues are more likely. By adjusting this parameter, administrators can finetune the balance between performance and reliability according to their application's needs.

The value set for nchan_redis_retry_commands primarily impacts the responsiveness of the service. A higher value may lead to longer wait times before a failure is reported, as operations will be retried multiple times. Conversely, a lower setting may result in quicker error feedback but could increase the risk of message loss during brief Redis downtime periods.

Additionally, careful monitoring should be undertaken to assess the impact of retry strategies in live operation, ensuring that it meets the application's requirements without introducing undue latency or resource consumption.

Config Example

upstream my_redis {
    nchan_redis_retry_commands 3;
    server 127.0.0.1:6379;
}

Setting the retry count too high can lead to increased latency in failure detection.

A value of 0 is not allowed, as that wouldn't make sense for retry attempts.

Be mindful of how this setting interacts with other timeout configurations to avoid blocking behavior.

← Back to all directives