How can I get lock result within a fixed time interval?

[dpastorc]

Hello,

I want to acquire the ownership of a lock (using etcd3 lock feature) but the lock operation should be completed within a maximum time interval. I mean that I would like to get the lock in the following N seconds, if isn't possible then it should fail and abort the operation. I cannot be waiting indefinitely to get the lock.

I can try to do something like this:

std::future<etcd::Response> future = std::async(std::launch::async, [&](){
   auto lease_response = client.leasegrant(ttl).get;
   auto response = client.lock_with_lease(prefix, lease_response.value().lease()).get();
   return response;
});
std::future_status status = future.wait_for(std::chrono::seconds(timeout));
if (status == std::future_status::ready) {
   auto resp = future.get();
   if (resp.is_ok()) {
      std::cout << "Lock acquired" << std::endl;
   }
} else if (status == std::future_status::timeout) {
      std::cerr << "Error: failed to acquire lock, operation timeout" << std::endl;
} else {
      std::cerr << "Error: failed to acquire the lock" << std::endl;
}

Although with this approach I don't get blocked there is a problem, because it's possible that the future.wait_for()could return by timeout although the lock will be really created (only the success answer has not arrived on time).

I searched for similar questions and although #34 (now closed) seems add a timeout per client operation, I think that could be interesting feature but it doesn't solve how to abort tge on going lock operation, so the lock will be created in regular scenario. This is also an issue due the dangled lock is created (but it will not be used by the client and then will expire) and it could block other clients that want to create a lock using the same prefix.

There is any option to cancel an ongoing etcd operation?
Perhaps it could be adding support for gRPC call deadline (though ClientContext), as suggests #102
Any ideas?

Thanks in advance.

[sighingnow]

Currently timeout and canceling on-wire operation is not supported.

Hopefully to be fixed within two weeks.

[sighingnow]

Related to #3

[dpastorc]

Currently timeout and canceling on-wire operation is not supported.

Hopefully to be fixed within two weeks.

Great!!

[dpastorc]

Currently timeout and canceling on-wire operation is not supported.

Hopefully to be fixed within two weeks.

Hi,

@sighingnow Any news about this? Do you have a new estimate about when it could it be completed and published?

Best regards.

[sighingnow]

I have just finished the decoupling of API and thread model (discussed in #100). The timeout feature for whole API set will be finished in this week.

Apology for the delay.

[sighingnow]

Closed by #131.

You could find a "lock can be timeout" test case in that pull requset.