-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Concurrency issue in redis-rb 4.6.0 (using redis-namespace) #1088
Comments
That would suggest that the Lines 171 to 172 in 610c783
Do you use I'd suggest something to your connection pool to make sure |
Thanks for the quick response. |
It's possible some other gem might use it. Either way, short term I really recomend the modified connection pool, both to find the source of the problem, and to negate it's impact. Basically when the connection is checked back in the pool, you want to inspect it to make sure a pipeline didn't leak. I reviewed the code, and there's no fundamental change on how |
Fix: resque#191 Fix: redis/redis-rb#1088 In redis-rb 4.6.0, the object yielded by `multi` and `pipelined` is an unsynchronized `PipelinedConnection` object. This changed opened a thread safety issue in Redis::Namespace: - T1: `redis.multi do`, sets `Namespace#redis = PipelinedConnection` - T2: any command called before T1 exists the `multi` block is called on the pipelined connection
Most of the discussion on this issue actually happened on an unrelated one: #1069 (comment) |
Fix: resque#191 Fix: redis/redis-rb#1088 In redis-rb 4.6.0, the object yielded by `multi` and `pipelined` is an unsynchronized `PipelinedConnection` object. This changed opened a thread safety issue in Redis::Namespace: - T1: `redis.multi do`, sets `Namespace#redis = PipelinedConnection` - T2: any command called before T1 exists the `multi` block is called on the pipelined connection
Fix: resque#191 Fix: redis/redis-rb#1088 In redis-rb 4.6.0, the object yielded by `multi` and `pipelined` is an unsynchronized `PipelinedConnection` object. This changed opened a thread safety issue in Redis::Namespace: - T1: `redis.multi do`, sets `Namespace#redis = PipelinedConnection` - T2: any command called before T1 exists the `multi` block is called on the pipelined connection
Fix: resque#191 Fix: redis/redis-rb#1088 In redis-rb 4.6.0, the object yielded by `multi` and `pipelined` is an unsynchronized `PipelinedConnection` object. This changed opened a thread safety issue in Redis::Namespace: - T1: `redis.multi do`, sets `Namespace#redis = PipelinedConnection` - T2: any command called before T1 exists the `multi` block is called on the pipelined connection
redis-namespace 1.8.2 is out: https://rubygems.org/gems/redis-namespace/versions/1.8.2 |
With the upgrade of redis-rb from 4.5.1 to 4.6.0 we started observing ocasional odd behavior under load:
A non-pipelined
redis.evalsha(sha, keys, args)
returning aRedis::Future
instead of a String causing an error when the application tries to parse it.And occasionally at the same time but in a different thread we noticed a misbehavior when a pipelined
exists?
wrongly evaluates to true.Although relatively rare they seem related with the redis-rb gem upgrade, since we updated our pipelines and sidekiq dependency to avoid deprecation warnings 1 week before upgrading redis-rb, without problem.
Using:
The text was updated successfully, but these errors were encountered: