Expose Redis#queue_key #1057
Expose Redis#queue_key #1057
Conversation
Prior to this commit, the Redis class maintains a queue mapping Thread.current.object_id to the current queue of not-yet-committed commands for the particular thread accessing the Redis client. This works for the common case where a Redis client is shared amongst multiple threads, but with Ruby 3's Fiber Scheduler and recent strides in the Async gem, we'll want a way to choose a different concurrency primitive (such as a Fiber-backed Async task) to map queues to. Previously we exposed `def synchronize` so that the concurrency scheme for checking out the Redis client could be overridden in subclasses, but internally the implicit queue key was hardwired to Thread.current.object_id. This commit takes a similar approach be exposing `def cache_key` so that it too can be overriden by Redis subclasses.
|
My plan was to just entirely get rid of that It's just gonna take a while to deprecate. |
|
I think that makes a lot of sense. I also felt the queue mutation was weird but wanted to pick the most conservative route iterating towards Fiber-safety. |
|
@byroot |
Like you said, it shouldn't break backward compat. Short term we should yield a The most important is to throw a deprecation warning if the original client is called from inside |
|
@byroot the Redis class uses a dynamic method_missing to forward commands to @client; is there some definitive list of known redis commands we could consult to issue proper deprecation warnings? |
No need. You can use proxy objects.
You can simply decorate with a Alternatively, you can raise a warning if the Yet another method would be to check the block arity. It's also not a strict or, some combinaison of the above might make sense. |
|
I have unfortunately run through my budget on being able to work on this; got a little sucked into corner cases involving nesting that I couldn't quite wrap my head around. Some thoughts for posterity:
|
We can add a
Definitely, it would just be a good way to catch obvious mistakes.
No worries. I'll find some time to do it. |
… block.
All theses make a lot of assumptions on the threading model and are barely
thread safe.
The new favored API is:
```ruby
redis.pipelined do |pipeline|
pipeline.get("foo")
pipeline.del("bar")
end
```
This API allow multiple threads to build pipelines concurrently on the same
connection, and is more friendly to Fiber based concurrency.
Fix: redis#1057
… block.
All theses make a lot of assumptions on the threading model and are barely
thread safe.
The new favored API is:
```ruby
redis.pipelined do |pipeline|
pipeline.get("foo")
pipeline.del("bar")
end
```
This API allow multiple threads to build pipelines concurrently on the same
connection, and is more friendly to Fiber based concurrency.
Fix: redis#1057
… block.
All theses make a lot of assumptions on the threading model and are barely
thread safe.
The new favored API is:
```ruby
redis.pipelined do |pipeline|
pipeline.get("foo")
pipeline.del("bar")
end
```
This API allow multiple threads to build pipelines concurrently on the same
connection, and is more friendly to Fiber based concurrency.
Fix: redis#1057
The new favored API is:
```ruby
redis.pipelined do |pipeline|
pipeline.get("foo")
pipeline.del("bar")
end
```
This API allow multiple threads to build pipelines concurrently on the same
connection, and is more friendly to Fiber based concurrency.
Fix: redis#1057
The new favored API is:
```ruby
redis.multi do |transaction|
transaction.get("foo")
transaction.del("bar")
end
```
This API allow multiple threads to build pipelines concurrently on the same
connection, and is more friendly to Fiber based concurrency.
Fix: redis#1057
…lock)
The new favored API is:
```ruby
redis.multi do |transaction|
transaction.get("foo")
transaction.del("bar")
end
```
This API allow multiple threads to build transactions concurrently on the same
connection, and is more friendly to Fiber based concurrency.
Fix: redis#1057
…lock)
The new favored API is:
```ruby
redis.multi do |transaction|
transaction.get("foo")
transaction.del("bar")
end
```
This API allow multiple threads to build transactions concurrently on the same
connection, and is more friendly to Fiber based concurrency.
Fix: redis#1057
…lock)
The new favored API is:
```ruby
redis.multi do |transaction|
transaction.get("foo")
transaction.del("bar")
end
```
This API allow multiple threads to build transactions concurrently on the same
connection, and is more friendly to Fiber based concurrency.
Fix: redis#1057
…lock)
The new favored API is:
```ruby
redis.multi do |transaction|
transaction.get("foo")
transaction.del("bar")
end
```
This API allow multiple threads to build transactions concurrently on the same
connection, and is more friendly to Fiber based concurrency.
Fix: redis#1057
…lock)
The new favored API is:
```ruby
redis.multi do |transaction|
transaction.get("foo")
transaction.del("bar")
end
```
This API allow multiple threads to build transactions concurrently on the same
connection, and is more friendly to Fiber based concurrency.
Fix: redis#1057
…lock)
The new favored API is:
```ruby
redis.multi do |transaction|
transaction.get("foo")
transaction.del("bar")
end
```
This API allow multiple threads to build transactions concurrently on the same
connection, and is more friendly to Fiber based concurrency.
Fix: redis#1057
…lock)
The new favored API is:
```ruby
redis.multi do |transaction|
transaction.get("foo")
transaction.del("bar")
end
```
This API allow multiple threads to build transactions concurrently on the same
connection, and is more friendly to Fiber based concurrency.
Fix: redis#1057
Prior to this commit, the Redis class maintains a queue
mapping Thread.current.object_id to the current queue of
not-yet-committed commands for the particular thread
accessing the Redis client. This works for the common
case where a Redis client is shared amongst multiple
threads, but with Ruby 3's Fiber Scheduler and recent
strides in the Async gem, we'll want a way to choose a
different concurrency primitive (such as a Fiber-backed
Async task) to map queues to. Previously we exposed
def synchronizeso that the concurrency scheme forchecking out the Redis client could be overridden in
subclasses, but internally the implicit queue key was
hardwired to Thread.current.object_id. This commit takes
a similar approach be exposing
def cache_keyso that ittoo can be overriden by Redis subclasses.