Revision 36452a1c1d43f8f90511642643a5b3aff2d00391 authored by Jack Kleeman on 06 May 2020, 10:57:19 UTC, committed by tangcong on 23 June 2020, 11:50:21 UTC
Currently, watch cancel requests are only sent to the server after a message comes through on a watch where the client has cancelled. This means that cancelled watches that don't receive any new messages are never cancelled; they persist for the lifetime of the client stream. This has negative connotations for locking applications where a watch may observe a key which might never change again after cancellation, leading to many accumulating watches on the server. By cancelling proactively, in most cases we simply move the cancel request to happen earlier, and additionally we solve the case where the cancel request would never be sent. Fixes #9416 Heavy inspiration drawn from the solutions proposed there.
1 parent 37ac222
| File | Mode | Size |
|---|---|---|
| adt | ||
| contention | ||
| cpuutil | ||
| crc | ||
| debugutil | ||
| expect | ||
| fileutil | ||
| flags | ||
| httputil | ||
| idutil | ||
| ioutil | ||
| logutil | ||
| mock | ||
| netutil | ||
| osutil | ||
| pathutil | ||
| pbutil | ||
| proxy | ||
| report | ||
| runtime | ||
| schedule | ||
| srv | ||
| stringutil | ||
| systemd | ||
| testutil | ||
| tlsutil | ||
| traceutil | ||
| transport | ||
| types | ||
| wait | ||
| README.md | -rw-r--r-- | 194 bytes |
Computing file changes ...
