Recovery Request Queue

When a cluster client receives a circular MOVED redirect, the target endpoint is redirecting the client back to itself. This can happen when a stable endpoint still leads to a former primary. GLIDE enters recovery to replace the stale connection even if that connection still responds to PING. The recovery request queue buffers requests only during fast reconnect and RefreshingSlots recovery. If recovery escalates to reconnecting through the initial nodes, GLIDE fails new and already buffered requests with ClientError("Connection in recovery").

Configuration

Configure the recovery request queue size through the cluster client configuration.

Java

// Buffer up to 2000 requests during cluster recovery
GlideClusterClientConfiguration config = GlideClusterClientConfiguration.builder()
    .address(NodeAddress.builder().host("localhost").port(6379).build())
    .recoveryRequestsQueueSize(2000)
    .build();

Python

# Buffer up to 2000 requests during cluster recovery
config = GlideClusterClientConfiguration(
    addresses=[NodeAddress(host="localhost", port=6379)],
    recovery_requests_queue_size=2000,
)

Node

// Buffer up to 2000 requests during cluster recovery
const config: GlideClusterClientConfiguration = {
    addresses: [{ host: "localhost", port: 6379 }],
    recoveryRequestsQueueSize: 2000,
};

Go

// Buffer up to 2000 requests during cluster recovery
clientConfig := config.NewClusterClientConfiguration().
    WithAddress(&config.NodeAddress{Host: "localhost", Port: 6379}).
    WithRecoveryRequestsQueueSize(2000)

PHP

Note

This feature is not yet available in GLIDE PHP.

C#

Note

This feature is not yet available in GLIDE C#.

How It Works

1. Trigger: The cluster client encounters a circular MOVED redirect or begins a slot-map refresh.
2. Recover: GLIDE starts a fast reconnect for a circular redirect or enters RefreshingSlots for a topology refresh.
3. Buffering: During either fast path, incoming requests enter a bounded FIFO queue instead of failing immediately.
4. Complete or escalate: Successful recovery dispatches buffered requests in FIFO order with their full retry budgets. If recovery escalates to reconnecting through the initial nodes, GLIDE fails queued and new requests with ClientError("Connection in recovery").
5. Overflow: If the queue is full, additional requests are failed immediately with an error. This prevents unbounded memory growth during prolonged recovery windows.

When to Adjust

Scenario	Recommendation
High-throughput workloads with busy fast-recovery windows	Increase the queue size to absorb more requests before the queue fills
Memory-constrained environments	Decrease the queue size to limit memory usage during recovery
Application handles retries at a higher level	Set to 0 to disable the queue and restore fail-fast behavior
Short-lived bursts with fast recovery	The default of 1000 is typically sufficient

Disabling the queue: Setting recovery_requests_queue_size to 0 restores the previous behavior where requests arriving during recovery are failed immediately. This is useful when your application already implements retry logic above the client layer and you prefer immediate feedback over transparent buffering.

Defaults

The default recovery request queue size is 1000. This applies only to cluster clients (GlideClusterClient). Standalone clients use a different reconnection mechanism and do not encounter circular MOVED redirects, so this option has no effect on them.