Convenient invariant:
- if werr == nil then lock is supposed to be locked at the moment.
While we could not be confident in stronger invariant ('is exactly locked'),
it were inconvenient that previous code could return `werr == nil` after
Mutex.Unlock.
It could happen when ctx is canceled/timeouted exactly after waitDeletes
successfully returned werr == nil and before `<-ctx.Done()` checked.
While such situation is very rare, it is still possible.
fixes#10111
We should allow etcd client use all of the available keepalive
client parameters as documented in this link,
https://godoc.org/google.golang.org/grpc/keepalive#ClientParameters
Currently in the etcd, by default PermitWithoutStream is set to
false, and user has no way to override it.
On the server side, we explicitely setting EnforcementPolicy
PermitWithoutStream to false and don't provide option to override it
to user but on the client side we should allow this option as
provided by the grpc.
Go 1.11 now marks len(channel) over being-closed channel
as racey operation, fix tests by receiving from channel first
and then check the length of channel.
```
WARNING: DATA RACE
Write at 0x00c000e872c0 by goroutine 198:
runtime.closechan()
/usr/local/go/src/runtime/chan.go:327 +0x0
go.etcd.io/etcd/clientv3.(*lessor).closeRequireLeader()
/Users/leegyuho/go/src/go.etcd.io/etcd/clientv3/lease.go:379 +0x748
go.etcd.io/etcd/clientv3.(*lessor).recvKeepAliveLoop()
/Users/leegyuho/go/src/go.etcd.io/etcd/clientv3/lease.go:455 +0x3a5
Previous read at 0x00c000e872c0 by goroutine 27:
go.etcd.io/etcd/clientv3/integration.TestLeaseWithRequireLeader()
/Users/leegyuho/go/src/go.etcd.io/etcd/clientv3/integration/lease_test.go:828 +0x810
testing.tRunner()
/usr/local/go/src/testing/testing.go:827 +0x162
```
Signed-off-by: Gyuho Lee <leegyuho@amazon.com>
This change allows Watch users to retrieve the cancel reason when a
watch is canceled by the server. Additionally WatchResponses with
closeErr set now have Canceled set true which is in line with the
documentation for the Canceled field.
client should update next keepalive send time
even when lease keepalive response queue becomes full.
Otherwise, client sends keepalive request every 500ms
regardless of TTL when the send is only expected to happen
with the interval of TTL / 3 at minimum.
Signed-off-by: Gyuho Lee <gyuhox@gmail.com>
Shin'ya Ueoka