-
Notifications
You must be signed in to change notification settings - Fork 9.7k
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
clientv3/concurrency Unable to use Mutex, m.Lock() never returns #6631
Comments
That should work. Are the client and server versions matched? The 3.1 client locks use a feature that's not available in 3.0 to reduce the amount of network traffic on the wait path. There may be a stray key on the lock prefix that's not associated with any lease. What does |
It prints out
Yes the client is up-to-date and server also. But thanks for telling me it should work, at least, I'll be able to focus my tests en etcd versions. |
@Soulou Have you figured this out? Tried myself, lock seems to work. |
@Soulou Had the same issue when accidentally updated client to v3.1.x, running v3.0.7 server. It works fine if versions are the same (running on v3.0.12 now). |
There is an issue tracking client versioning here: #6579. Please watch that issue if you are interested. |
Regardless if client or server are not at the correct version, the client should not hang indefinitely. Think about misconfigured hostnames. |
I'm currently trying to use the new
clientv3/concurrency
API, but a single call tomutex.Lock()
nevers returns.Here is the PoC:
The code never gets out of the
NewMutex
call. (After investigation, it is kept in thewaitDelete
function)I've tried with
3.0.12
and3.1.0-alpha1
, the behavior is identical.Am I misusing the API? In this case, is it possible to get an example of how it is supposed to work?
Thanks a lot,
The text was updated successfully, but these errors were encountered: