-
Notifications
You must be signed in to change notification settings - Fork 10
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
Dropped error in etcd/v2
lets multiple clients think they've acquired a lock.
#50
Comments
Thank you for the report @jlhawn ,
Returning to the core of the issue, I think we assumed that if the first call to This should be easy enough to fix, feel free to submit a patch or I'll do this if I have some free time. |
There's some bad error checking around here:
libkv/store/etcd/v2/etcd.go
Lines 528 to 534 in 5e4bb28
Where if the error is not of type
etcd.Error
then it is ignored completely. Then, another request toSet()
the key is made with thePrevIndex
value not set. This will just overwrite whatever value was at that key as long as it already exists. This results in two processes thinking they have acquired the lock at the same time. This only occurs under the condition that the firstSet
call fails due to some transient connection issue and the second call succeeds. We have seen this occur several times.Why is there even a second call to
Set()
the key? Why not immediately go into a wait loop if the firstSet()
attempt results inetcd.ErrorCodeNodeExist
?The text was updated successfully, but these errors were encountered: