-
-
Notifications
You must be signed in to change notification settings - Fork 42
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
Remove RepositoryManager RwLock #1007
Conversation
This should not be needed. And it might lead to write lock starvation. Typically cliens would call list before sending updates and not send two requests at the same time. In case we don't have the read lock then the content may not contain an update for another publisher, but that is irrelevant here.
I can understand why the previous deadlock happened, but I am not certain something similar could not still happen with the current locks in the |
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.
Approved following a deep dive in the code and several discussions with @tim.
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.
As far as I can see this should not cause any issues
[draft] We should make a branch for
prep-0.12.2
and merge to that if this is stable.This PR removes the RwLock in RepositoryManager.
We saw issues where a busy Krill Publication Server would freeze without any reported issues. We suspect that this may be due to a deadlock or lock starvation issue in RepositoryManager. A version where read locks were no longer acquired (they are actually not needed) - was deployed and so far seems stable.
Then one more commit was done to remove the RwLock altogether in this layer. It is in fact not needed because there are existing RwLocks in the layers below this (
WalStore::send_command
) to ensure that actual updates do happen sequentially.