feature request: allow `UNBLOCK`ing a blocking call before cancelling it to reuse the connection later for better performance

[davidxia]

👋 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?

[rueian]

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

	if resp.NonRedisError() != nil { // abort the wire if blocking command return early (ex. context.DeadlineExceeded)
	wire.Close()
	}

And it should look like the following:

1. Check whether the cmd is 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.
2. Check whether the 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.
3. Check whether 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.
4. Now, we can do the UNBLOCK: We don't close the wire and don't return it to the pool in the current m.blocking function. Instead, we need to create another goroutine to send the UNBLOCK command with m.pipeline(context.Background(), unblock) and only return the wire to the pool without closing it when the UNBLOCK command gets a response saying that the wire is unblocked successfully; Otherwise, we still close the wire before returning it to the pool.

[davidxia]

@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]

Hi @davidxia, do you need any help?

[davidxia]

Hi @davidxia, do you need any help?

I haven't gotten around to this yet. Will take a look today or early next week!