Repository navigation
Add option to actually skip WAIT command for locks (checkLockSyncedSlaves only suppresses the exception, not the WAIT call) #7321
Description
Is your feature request related to a problem? Please describe.
Setting checkLockSyncedSlaves(false) does not skip the WAIT command / replica sync check itself — Redisson still sends WAIT and waits for the replicas to acknowledge as part of evalWriteAsync. The flag only controls whether an exception ("Only X of Y slaves were synced") is thrown afterward based on the result. This means the latency cost of WAIT is still incurred even when this option is disabled.
In our case, the database layer already has its own mechanism to detect and reject conflicting writes, so we don't need Redisson's replica-sync guarantee for locks, and the extra WAIT round-trip only adds unnecessary latency.
Describe the solution you'd like
Add a configuration option that actually skips sending the WAIT command / replica-sync check entirely (not just suppressing the resulting exception), so users who don't need this guarantee can avoid the added latency altogether.
Describe alternatives you've considered
checkLockSyncedSlaves(false)— does not help, since the WAIT call and wait time still happen; it only avoids throwing on the result.
Activity
flojon commentedon Oct 6, 2026
+1. Here are measurements from a production-like setup, in case they help with prioritising this.
Setup: Redisson 3.52.0, Sentinel mode, Redis 8, one master plus two replicas, AOF on (
appendfsync everysec), replication healthy.Cost per lock call (
RPermitExpirableSemaphore):checkLockSyncedSlaves=truecheckLockSyncedSlaves=falseSET NX PX+ Lua compare-and-deleteRaw
redis-clion the same setup, after a write:WAIT 2 1000returns in 4–10 msWAITAOF 1 2 1000takes 1.0–1.1 s on every callSo with AOF on, 3.46–3.x pays about a second on every lock and semaphore call, whatever
checkLockSyncedSlavesis set to. 4.x switches locks toSyncMode.WAIT, which makes the healthy case cheap. But as this issue says, theWAITis still sent, so the fullslavesSyncTimeoutcomes back whenever a replica falls behind. We saw that in another environment, with about 1 s per call.A related side effect: when the replica wait times out, the script is retried (
syncedEvalWithRetry). The release script isn't idempotent, so on retrytryReleasecan't find the permit it has just removed and returnsfalse, even though the permit was released. We saw this as release calls taking 2–6 s and logging "release failed" warnings, while mutual exclusion was never actually broken. I haven't reproduced this on 4.8.0 yet, buttryReleasestill goes through the same retry path there.The error message "…or set checkLockSyncedSlaves = false" also suggests the flag avoids the wait, which it doesn't; that confused us at first.
We worked around it by replacing the semaphore with
SET NX PXplus a Lua compare-and-delete, since we don't need replica-confirmed locks. A config option that skips the wait altogether, as this issue asks for, would have let us keep using Redisson's lock types.