This is a backporting cherry-pick of the following commits:
- add flagsline
Signed-off-by: Jalin Wang <JalinWang@outlook.com>
- etcdserver: rename defaultCompactionSleepInterval var (#18495)
etcdserver: rename `minimumBatchInterval` to `defaultCompactionSleepInterval` and `defaultCompactBatchLimit` to `defaultCompactionBatchLimit`
Signed-off-by: Jalin Wang <JalinWang@outlook.com>
(cherry picked from commit 2c53be7c5d91e9b618342d63d2d06c3b265abee4)
- test: add CompactionSleepInterval in FakeStore's config
After setting the ComparionSleepInterval, we can use time.Ticker
instead of time.After to optimize the scheduleComparison(),
otherwise it will fail in the 'TestStoreCompact(t)' test.
Signed-off-by: guozhao <guozhao@360.cn>
(cherry picked from commit fab8474ef8370a089fe0174e28c197b5b93898df)
- add sleep interval
(cherry picked from commit 184b0e5d4964f1115590acec50fa5e584a2f7770)
Signed-off-by: Jalin Wang <JalinWang@outlook.com>
Signed-off-by: Wei Fu <fuweid89@gmail.com>
(cherry picked from commit 6f93af85d2aacbc85948f1db07e07f1a86698366)
Signed-off-by: Wei Fu <fuweid89@gmail.com>
Before this patch, the tombstone can be deleted if its revision is equal
compacted revision. It causes that the watch subscriber won't get this
DELETE event. Based on Compact API[1], we should keep tombstone revision
if it's not less than the compaction revision.
> CompactionRequest compacts the key-value store up to a given revision.
> All superseded keys with a revision less than the compaction revision
> will be removed.
[1]: https://etcd.io/docs/latest/dev-guide/api_reference_v3/
Signed-off-by: Wei Fu <fuweid89@gmail.com>
(cherry picked from commit bbdc94181a6d67904b575ad936c20d1be10e220c)
Signed-off-by: Wei Fu <fuweid89@gmail.com>
Signed-off-by: Wei Fu <fuweid89@gmail.com>
(cherry picked from commit ee33652775842b96d1c0ab601ec3002078998c2a)
Signed-off-by: Wei Fu <fuweid89@gmail.com>
The Go runtime uses runtime Finalizer to delete cert [[1]]. The
interestingGoroutines is able to collect stack like,
```plain
leak.go:103: Found leaked goroutined BEFORE test appears to have leaked :
sync.(*Map).LoadAndDelete(0xc00031e180, {0xe07320, 0xc00009fde0})
/usr/local/go/src/sync/map.go:272 +0x192
sync.(*Map).Delete(...)
/usr/local/go/src/sync/map.go:297
crypto/tls.(*certCache).evict(...)
/usr/local/go/src/crypto/tls/cache.go:73
crypto/tls.(*certCache).active.func1(0x0?)
/usr/local/go/src/crypto/tls/cache.go:65 +0x67
```
It's caused by GC instead of leaky goroutine. interestingGoroutines
should skip it.
Backport of #18287
[1]: 8e1fdea831/src/crypto/tls/cache.go (L63)
Signed-off-by: Wei Fu <fuweid89@gmail.com>
The goal is to reproduce a DELETE event being dropped in a watch after a compaction
occurs on the revision where the deletion took place. In order to reproduce this, we
perform the following sequence (steps for reproduction thanks to @ahrtr):
- PUT k v2 (assume returned revision = r2)
- PUT k v3 (assume returned revision = r3)
- PUT k v4 (assume returned revision = r4)
- DELETE k (assume returned revision = r5)
- PUT k v6 (assume returned revision = r6)
- COMPACT r5
- WATCH rev=r5
We should get the DELETE event (r5) followed by the PUT event (r6). However, currently we only
get the PUT event with returned revision of r6 (key=k, val=v6).
Signed-off-by: Madhav Jivrajani <madhav.jiv@gmail.com>
(cherry picked from commit ebf2cac6bda38892121585d2467982da54e60ef1)
Signed-off-by: Wei Fu <fuweid89@gmail.com>
