Repository navigation
feature request: allow UNBLOCKing a blocking call before cancelling it to reuse the connection later for better performance #897
Description
👋 My team enables pipelining for specific requests by using ToPipe when building the command object. This gives us the following behavior when a blocking request is made.
- Rueidis tries to acquire a wire (a wrapper around a connection) from the dedicated pool.
- If the pool has no available connections, we create a new pipe (pipe is an implementation of the wire interface).
- We execute the command
- If the request is successful, we return the wire to the dedicated pool. The wire will be reused on the next request.
- If the request’s context is cancelled (or fails for some other reason like a network timeout), we try to return the wire back to the dedicated pool, but because the wire is closed, the pool does not accept it. A new wire will be created for subsequent requests.
This solves the problem of ensuring we don’t open too many connections, but has the downside that every time we cancel a blocking call, the connection is closed. It would be more performant to issue an UNBLOCK command (which tells Redis to stop blocking), and then we can reuse the connection.
Is this a reasonable feature request? If so, are you open to contributions?
Activity
rueian commentedon Sep 12, 2025
Hi @davidxia, nice to meet you here!
I think that is a worthwhile optimization! We are open to contributions for sure.
So, I think the optimization for the blocking
.Do()should be done inside this block:rueidis/mux.go
Lines 269 to 271 in 5b78011
And it should look like the following:
cmdis a blocking command or not; If not, then we should close the wire and return it to the pool directly and skip all the following procedures.resp.NonRedisError()is a context error; If not, then we should close the wire and return it to the pool directly and skip all the following procedures.wire.Error()is nil or not; if not, then the wire is already closed. We should return the wire to the pool directly and skip all the following procedures.UNBLOCK: We don't close the wire and don't return it to the pool in the currentm.blockingfunction. Instead, we need to create another goroutine to send theUNBLOCKcommand withm.pipeline(context.Background(), unblock)and only return the wire to the pool without closing it when theUNBLOCKcommand gets a response saying that the wire is unblocked successfully; Otherwise, we still close the wire before returning it to the pool.davidxia commentedon Sep 12, 2025
@rueian yes, I was glad to see you're the maintainer of this project! Thanks so much for the guidance. I'll make a PR soon. 🙏
rueian commentedon Oct 3, 2025
Hi @davidxia, do you need any help?
davidxia commentedon Oct 3, 2025
I haven't gotten around to this yet. Will take a look today or early next week!
feat: put CLIENT UNBLOCK on cancel behind ClientOption.UnblockOnCancel
test: cover UnblockOnCancel with DisableAutoPipelining and ToPipe
docs: note UnblockOnCancel does not cover DedicatedClient
docs: warn against UnblockOnCancel behind proxies and load balancers
refactor: drop noUnblock and always try CLIENT UNBLOCK when enabled
feat: add UnblockOnCancel to CLIENT UNBLOCK cancelled blocking commands
feat: add UnblockOnCancel to CLIENT UNBLOCK cancelled blocking commands
feat: add UnblockOnCancel to CLIENT UNBLOCK cancelled blocking commands
feat: add UnblockOnCancel to CLIENT UNBLOCK cancelled blocking commands
feat: add UnblockOnCancel to CLIENT UNBLOCK cancelled blocking commands
feat: add UnblockOnCancel to CLIENT UNBLOCK cancelled blocking commands
feat: add UnblockOnCancel to CLIENT UNBLOCK cancelled blocking commands
feat: add UnblockOnCancel to CLIENT UNBLOCK cancelled blocking commands
feat: add UnblockOnCancel to CLIENT UNBLOCK cancelled blocking commands
KartikYZ commentedon Oct 6, 2026
Hi! I've opened a PR that implements the guidance above, #1030.
feat: CLIENT UNBLOCK cancelled blocking commands to reuse the connect…
feat: CLIENT UNBLOCK cancelled blocking commands to reuse the connect…