-
Notifications
You must be signed in to change notification settings - Fork 69
Ensure EXISTS key is not orphaned when expire is used #39
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
base: master
Are you sure you want to change the base?
Conversation
spec/semaphore_spec.rb
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing space after #.
|
Hey @jcalvert this looks good, thanks so much for contributing! Could you check out the CI errors and see if you could get them fixed? If you can also fix the hound comments that'd be great! I'll merge it then, thanks! |
|
@dv I'll try to clean this up here soon! |
072236e to
23bd45e
Compare
spec/semaphore_spec.rb
Outdated
|
|
||
| it "does not leave a key without expiration if expiration given" do | ||
| queue = Queue.new | ||
| threads = 2.times.map do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use Array.new with a block instead of .times.map.
…ng orphaned. We share redis clients between threads (redis obj is threadsafe) and because of this the 2nd thread will be blocking, waiting for the AVAILABLE key and thus the first thread is unable to finish cleanup. Eventually the AVAILABLE key expires but the EXISTS key does not. The failure to succeed with the signal() call could be due to loss of network connection, process crash, etc. Leaving an unexpiring EXISTS key but no AVAILABLE key means that a retry will believe the semaphore exists and wait for the AVAILABLE which never comes.
23bd45e to
30d028c
Compare
…ist will obviate it anyway and since keys can expire during a MULTI transaction anyway. Return the removed statement where we always reset the key expiration prior to attempting to obtain a lock. This prevents the orphaned EXISTS key that never expires.
30d028c to
6ac21c3
Compare
|
@dv I believe I have cleaned up the pull request. Thanks! |
|
👍 for this |
|
Has there been any further work on this? We're running into this issue on production as well - I'd be happy to take a look at the code if this has been abandoned. |
|
@jasonl AFAIK there's no further work to be done. I did the HoundCI cleanup and the tests pass; whatever Travis failures are there seem to be unrelated. We used a fork with my patch in production at my previous employer. |
TL;DR - GETSET resets the TTL on a key to indefinite. We need to ensure a key always has a TTL if using
:expirationAn observed and rare production (1 in a million) phenomenon has been a deadlock condition when timeouts on expiring locks are not used. Upon inspection of Redis, we could see that the EXPIRES key was present, but without a TTL and the AVAILABLE key was not.
The problem occurs because in the fix for block syntax in b0bbfda removed setting the expiration explicitly when the
EXISTSkey already exists. IEtoken = @redis.getset(exists_key, EXISTS_TOKEN)returns a non-nil result.This is problematic because the
getsetresets the TTL. You can see this demonstrated in Redis:This now opens up the possibility that one process is in the critical section, a second process resets the TTL on the
EXISTSkey and then waits viaBLPOPfor the first process to complete. If somehow theAVAILABLEkey expires, the second process will be waiting either indefinitely or until the lock times out. If the lock times out and is then retried, theEXISTSkey will still be there forever and not expire, so it will again wait without completing. If the expiration is set explicitly afterGETSET, then the retry will be successful after the expiration period because the semaphore will create a new set of keys.CC @dany1468 @dv