clientv3/concurrency Unable to use Mutex, m.Lock() never returns

[Soulou]

I'm currently trying to use the new clientv3/concurrency API, but a single call to mutex.Lock() nevers returns.

Here is the PoC:

    c, err := clientv3.New(clientv3.Config{
        Endpoints:   []string{"172.17.0.1:2379"},
        DialTimeout: 5 * time.Second,
    })
    if err != nil {
        panic(err)
    }

        lockKey := "/lock"
    session, err := concurrency.NewSession(c)
    if err != nil {
        panic(err)
    }
    m := concurrency.NewMutex(session, lockKey)
    if err := m.Lock(context.TODO()); err != nil {
        panic(err)
    }
        // The code never gets there.
        fmt.Println(m)

The code never gets out of the NewMutex call. (After investigation, it is kept in the waitDelete function)

I've tried with 3.0.12 and 3.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,

[heyitsanthony]

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 ETCDCTL_API=3 ./bin/etcdctl -w=json get --prefix "/lock" print out?

[Soulou]

It prints out

{"header":{"cluster_id":8630471378722434275,"member_id":2307798685123013129,"revision":339,"raft_term":54}}

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.

[xiang90]

@Soulou Have you figured this out? Tried myself, lock seems to work.

[dennwc]

@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).

[xiang90]

@Soulou @dennwc I am going to close this since I believe this is a client/server versions incompatibility issue.

[xiang90]

There is an issue tracking client versioning here: #6579. Please watch that issue if you are interested.

[gm42]

Regardless if client or server are not at the correct version, the client should not hang indefinitely. Think about misconfigured hostnames.