-
Notifications
You must be signed in to change notification settings - Fork 26
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
馃悰Introduce timeout in project lock (a la aioredlock) #3675
馃悰Introduce timeout in project lock (a la aioredlock) #3675
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3675 +/- ##
========================================
+ Coverage 84.3% 84.7% +0.3%
========================================
Files 883 734 -149
Lines 37382 31939 -5443
Branches 785 415 -370
========================================
- Hits 31545 27073 -4472
+ Misses 5629 4742 -887
+ Partials 208 124 -84
Flags with carried forward coverage won't be shown. Click here to find out more.
|
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.
Very nice! Thanks for addressing this!
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.
馃憤
96c53cd
to
4198e81
Compare
Kudos, SonarCloud Quality Gate passed!聽 聽 0 Bugs No Coverage information |
What do these changes do?
Previously we were using aioredlock to lock projects. When we migrated to redis-py, we lost the automatic timeout extension of distributed locks. This probably led to the following issues:
ITISFoundation/osparc-issues#724
#3145
in case of a crash in the webserver, these locks would never timeout.
This PR aims to fix this by mimicking the behavior of aioredlock (default timeout of 10 seconds, with auto-extension every 6 seconds). In case the webserver would restart/crash without having the time to release the lock, this would ensure the lock is released at some point.
This PR just fixes the ProjectLock, all the other locks are not concerned with this change.
just looking at master's redis-commander shows how this is a problem, most of these locks are lost:
Related issue/s
How to test
Checklist