Signed-off-by: Wei Fu <fuweid89@gmail.com>
(cherry picked from commit 6f93af85d2aacbc85948f1db07e07f1a86698366)
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 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>
Backports a657f06, 22f20a8, 497f1a4 and 3e86af6 from #18186.
Also backports required test util elements of 4c77726 from #17661.
Signed-off-by: James Blair <mail@jamesblair.net>
gRPC health server sets serving status to NOT_SERVING on defrag
Backport from 3.6 in #16278
Co-authored-by: Chao Chen <chaochn@amazon.com>
Signed-off-by: Thomas Jungblut <tjungblu@redhat.com>
Signed-off-by: Wei Fu <fuweid89@gmail.com>
(cherry picked from commit 71733911544f8fce6d06d2a8e9cca0944b3659be)
Signed-off-by: Wei Fu <fuweid89@gmail.com>
Backported PR #16822, commits f7e488dc9262685d6624755e0d3bb0a655863248,
67f17166bf2ba337dafb8e0ea8eea5f74a990767,
and f7ff898fd6c2d6dbb54278343073aa4fa5f46a03
Signed-off-by: Ivan Valdes <ivan@vald.es>
Fix#15919.
Check ScheduledCompactKeyName and FinishedCompactKeyName
before writing hash to hashstore.
If they do not match, then it means this compaction has once been interrupted and its hash value is invalid. In such cases, we won't write the hash values to the hashstore, and avoids the incorrect corruption alarm.
Signed-off-by: caojiamingalan <alan.c.19971111@gmail.com>
Difference in load configuration for watch delay tests show how huge the
impact is. Even with random write scheduler grpc under http
server can only handle 500 KB with 2 seconds delay. On the other hand,
separate grpc server easily hits 10, 100 or even 1000 MB within 100 miliseconds.
Priority write scheduler that was used in most previous releases
is far worse than random one.
Tests configured to only 5 MB to avoid flakes and taking too long to fill
etcd.
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
There are two goroutines accessing the `gs` grpc server var. Before
insecure `gs` server start, the `gs` can be changed to secure server and
then the client will fail to connect to etcd with insecure request. It
is data-race. We should use argument for reference in the new goroutine.
fix: #15495
Signed-off-by: Wei Fu <fuweid89@gmail.com>
(cherry picked from commit a9988e2625eede1af81d189b5f2ecf7d4af3edf1)
Signed-off-by: Wei Fu <fuweid89@gmail.com>
