An open source Valkey client library that supports Valkey and Redis open source 6.2, 7.0 and 7.2. Valkey GLIDE is designed for reliability, optimized performance, and high-availability, for Valkey and Redis OSS based applications. GLIDE is a multi language client library, written in Rust with programming language bindings, such as Java and Python
Apache License 2.0
265
stars
55
forks
source link
Core: Refactored the connection container lock to use a sync RwLock #2643
Core: Refactored the Connection Container Lock to Use a Synchronous RwLock
This PR refactors the connection container lock to use a synchronous RwLock instead of an asynchronous one, ensuring that the lock is held only briefly and not across await points. This change addresses potential deadlocks and improves overall lock acquisition time.
Background
In the redis-rs implementation, the entire request pipeline is blocked while the cluster client is in a recovery state. Specifically, when poll_flush calls poll_recover, the system waits for the recovery future to complete before processing other tasks. During this recovery period, some in-flight requests may already be running but remain pending. This creates a risk of deadlock if a request holds the connection container lock while the recovery future is waiting for it.
Why the Change was Made
Switching to a synchronous lock ensures that the recovery state cannot be entered while the connection container lock is held, thus preventing the recovery future from getting stuck. By preventing requests from holding the lock across await points, we reduce the risk of deadlocks.
Core: Refactored the Connection Container Lock to Use a Synchronous RwLock
This PR refactors the connection container lock to use a synchronous RwLock instead of an asynchronous one, ensuring that the lock is held only briefly and not across await points. This change addresses potential deadlocks and improves overall lock acquisition time.
Background
In the redis-rs implementation, the entire request pipeline is blocked while the cluster client is in a recovery state. Specifically, when poll_flush calls poll_recover, the system waits for the recovery future to complete before processing other tasks. During this recovery period, some in-flight requests may already be running but remain pending. This creates a risk of deadlock if a request holds the connection container lock while the recovery future is waiting for it.
Why the Change was Made
Switching to a synchronous lock ensures that the recovery state cannot be entered while the connection container lock is held, thus preventing the recovery future from getting stuck. By preventing requests from holding the lock across await points, we reduce the risk of deadlocks.