Does this etcd4j provide lock function like "etcdctl lock mylock..."

[regardfs]

Hi, I want to figure out how do I use this package to fulfill the tasks of distribute key lock request, for now I use below shell scripts to handle this:

mkfifo mylock.fifo ETCDCTL_API=3 ./bin/etcdctl lock mylock >mylock.fifo & pid=$! if read lockname <mylock.fifo; then echo holding lock with key $lockname ... do whatever ... fi kill $pid wait $pid

But it is not the best solution，cause My other code is all written by java and this package module，do we support this. Thanks a lot for your feedback.

[lburgazzoli]

this client implements etcd v2 API only, for v3 there is https://github.com/coreos/jetcd you can implement something similar to a lock using PUT with prevExist / prevValue options.

[regardfs]

@lburgazzoli Thanks a lot, I closed this issue.

[regardfs]

@lburgazzoli , hi , I meet a very strange scenario, I use below code to lock my certain key, and five backend nodes run this code at same time.

try { response = etcdClient.put(etcdLockName, lockContent). prevExist(false). ttl((int) lockTtl.getSeconds()). send(). get(); do something; release(); } catch ( Exception ex ) { logger.error("sth"); }

Sometimes when one node acquired the lock

2017-06-23 14:42:45.646 INFO 49993 --- [tLoopGroup-2-14] o.s.c.config.etcd.EtcdLocks.EtcdLock : Try to acquire etcd lock... 2017-06-23 14:42:45.652 INFO 49993 --- [tLoopGroup-2-14] o.s.cloud.config.etcd.EtcdWatch : Successed acquired the etcd lock.

and others will raise Key already exists, cause: key, at index xxxx once and sometimeswill raise this exception again and again until acquired the lock then release.

2017-06-23 14:42:46.323 ERROR 50986 --- [ntLoopGroup-2-1] o.s.c.config.etcd.EtcdLocks.EtcdLock Error encountered when attempting to acquire lock mousio.etcd4j.responses.EtcdException: [105]: Key already exists, cause: ... ...

I could not figure out why generate different results when meet Exception?

I try to hack the code and I found

public static final RetryWithExponentialBackOff DEFAULT = new RetryWithExponentialBackOff(20, -1, 10000);

Is this the reason why try to acquire lock again and again? but why sometimes raise once and sometimes raise multi?

[lburgazzoli]

Need to digg into it, can you send a PR with a failing test ?

[regardfs]

@lburgazzoli for now I do not have time to make a PR, I would like to close this issue now, and will make PR when new guys join my team and let they do this.