-
Notifications
You must be signed in to change notification settings - Fork 165
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
Lock stuck in Conflicted state #107
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Package versions:
I have an instance where keys get "stuck" in a conflicted state. Below is the lock information:
The architecture is such that there are an n number of service instances running and each is configured as noted below. A possible important note here is that RedLock is being set up against a Redis Cluster.
At any given time, one of the running service instances can acquire a lock and any other service that requests the same lock will fail to acquire. This seems to be working. But as noted above, it looks like a lock will inadvertently get "stuck".
If a processes is indeed taking a long time to processes, I would expect the extendCount to be greater than zero. I suspect a long running process is not the issue bc the code to acquire the lock is running in a consumer for a Azure Service Bus message. Azure Service Bus has a default limit of 5 minute processing time before it throwing a message lost exception, which is not occurring in this case.
A possibility is that one of the processes gets the lock, but isn't disposing it properly? If this is the case, wouldn't extendCount be greater than zero as well? Could it be something with the usage of Redis Cluster?
The text was updated successfully, but these errors were encountered: