-
Notifications
You must be signed in to change notification settings - Fork 260
Reduce lock timeout and check pid same before cleaning up #1035
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
Conversation
7fd04e0 to
fc8b78c
Compare
fc8b78c to
274dfd6
Compare
|
|
||
| // Maximum number of retries before failing a lock call. | ||
| lockMaxRetries = 200 | ||
| lockMaxRetries = 100 |
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.
how quickly do we retry? this could go by very fast. should there be some exponential back-off, maybe?
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.
Isn't 10 seconds long enough? 100 retries with 100ms delay
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.
I don't know. Usually (like with http calls), we would do an exponential back-off where we wait maybe twice as long every time instead of a fixed interval (ex: 50ms, 100, 200, 400, 800, ...). But if 100x100ms is what we want, that's fine with me
Co-authored-by: Evan Baker <rbtr@users.noreply.github.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Reason for Change:
Issue Fixed:
Requirements:
Notes: