-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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 response when lease has expired #9921
Comments
In case of Perhaps in this case, an additional watch is required for the self key (in addition to the watch handling by @gyuho , what is your opinion. |
Thanks for commenting on this. That helps me better understand what's going on. BTW, I went with the second option listed above. That is, I have a timer in my client that fires if I have not acquired the lock in time and will ignore the returned lock that has already timed out. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions. |
I have a scenario where a lock is obtained even though the lease associated with the lock has expired.
I have a scenario where I have two processes that want to acquire a lock on the same lock name. The first process successfully acquires the lock using a
LockRequest
with a lease time-to-live of 20 seconds. Immediately after a second process tried to acquire the same lock name but with a lease time-to-live of only 5 seconds.After 20 seconds the first lease expires and the lock is released. This in turn sends a
LockResponse
from the Lock service back to the second process. The second process now thinks it has the lock even though it doesn't as it's lease has expired.Is this the expected behaviour?
I would have expected the
LockResponse
to return an error if aLockRequest
was not able to be acquired before its lease expired.If the above is expected behaviour, how are the clients meant to handle this scenario? I can see two solutions
LockResponse
to check thekey
actually has the lockOr have I completely misunderstood how distributed locks work with etcd?
The text was updated successfully, but these errors were encountered: