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
Enforcer hangs during multi-threaded modifications #336
Comments
Hi! Thank you for your feedback. I will review your points later and it would be helpful if you could provide more details like the error throw line. |
This happen in the Default PolicyStore.Node class in TryAddPolicy and TryRemovePolicy, lines 74 and 133 respectively. |
Hello! Any updates on this issue? |
@v-loboda @dmolochnikov can you provide stable reproduce steps? and also:
|
Hi, as I said before, it is hard to reprocude becase of multithreaded nature. You just need to modify your policies in several threads and read them simultaneously. In the first message I have pointed out several places that do not meet the multithreading requirements.
|
@v-loboda how to reproduce it stably? |
I would make a test case if I could reproduce the bug reliably. I was able to reproduce it several times by running the modification and receiving permissions in multiple threads and waiting for errors for a long time. Sometimes the error appeared within a few seconds. |
Hi guys
We encountered a problem in an environment where intensive policy modification occurs. It's very difficult to reproduce, and I can't do it reliably.
We have rbac model, several nodes with synchronization via IWatcher and a lot of policy changes including removing them.
Sometimes, very rarely, we catch an error
Error Write lock may not be acquired with read lock held. This pattern is prone to deadlocks. Please ensure that read locks are released before taking a write lock. If an upgrade is necessary, use an upgrade lock in place of the read lock.
From my point of view, there are 3 problem pleces:
The text was updated successfully, but these errors were encountered: