Deployment to github-pages by github-pages[bot] linkedin/venice

1 new commit pushed to

<https://github.com/linkedin/venice/tree/main|main>

by gaojieliu

<https://github.com/linkedin/venice/commit/0e86d322cdcbc184415374b6f37fdfeb19a91968|0e86d322>

- [dvc] [server] upgraded rocksdb dep to 8.8.1 (#791) linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice

1 new commit pushed to

<https://github.com/linkedin/venice/tree/main|main>

by majisourav99

<https://github.com/linkedin/venice/commit/1600847c90ec70ff11cc978e7d2e309619fe8cc9|1600847c>

- [controller][router] Safe backup version deletion (#760) linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice

#792 [fast-client] Wrong value schema id used when handling multi-get response in FC Pull request opened by xunyin8 [fast-client] Wrong value schema id used when handling multi-get response in FC batchGetTransportRequestCompletionHandler should obtain the correct dataRecordDeserializer by using the MultiGetResponseRecordV1's per record value schema id field. The handler was using the transport response header's schema id which is inteded for the protocol version and not the write schema version for the data records. As a result, FC is running into data issues when the user record's write schema id > 1 with new fields/data. How was this PR tested? Existing tests and new test to ensure the correct value schema id is obtained. Also war dropped to confirm the root cause and fix. Does this PR introduce any user-facing changes? ☑︎ No. You can skip the rest of this section. ☐ Yes. Make sure to explain your proposed changes and call out the behavior change. linkedin/venice ✅ All checks have passed 30/30 successful checks

#793 [router] Add current version metric Pull request opened by majisourav99 Add router current version metric This PR adds current version metric in router which gives us visibility of in-memory vcurrent version being served for a store in the router. How was this PR tested? CI Does this PR introduce any user-facing changes? ☑︎ No. You can skip the rest of this section. ☐ Yes. Make sure to explain your proposed changes and call out the behavior change. linkedin/venice GitHub Actions: IntegrationTestsZ (17) ✅ 28 other checks have passed 28/29 successful checks

1 new commit pushed to

<https://github.com/linkedin/venice/tree/main|main>

by adamxchen

<https://github.com/linkedin/venice/commit/ceff23f7253dbaf728b79646c0f4013045e28bce|ceff23f7>

- [doc] Add PlantUML diagrams for Venice (#783) linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice

1 new commit pushed to

<https://github.com/linkedin/venice/tree/main|main>

by m-nagarajan

<https://github.com/linkedin/venice/commit/8541dc4d685e892cfacbb4295d6b7fd62a4871a9|8541dc4d>

- [dvc][common][server][test]leader complete status part 2: DVC and standby completes based on the consumed leader complete status (#775) linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice

#794 [server] Add a new option to allocate dedicated consumer pool for leader replicas of AA/WC stores Pull request opened by gaojieliu Summary Based on the offline analysis, the logic to handle writes from Active/Active or Write-compute stores in consumer threads is much heavier than other stores, which would slow down the ingestion speed of regular stores significantly when there are some high write throughput to AA or WC stores. This code change introduces an option to assign the leader replicas of AA or WC stores to a dedicated consumer pool, so that the regular store ingestion won't be affected by the above combination. The write compute flag is store-level config, so it can change in the lifetime of a particular version, and this code change won't react of write compute flag change until a restart. New configs: server.dedicated.consumer.pool.for.aa.wc.leader.enabled: default false server.dedicated.consumer.pool.size.for.aa.wc.leader: default 5 This code change will introduce a new set of consumer service metrics with suffix:

_for_aa_wc_leader

when this feature is enabled. How was this PR tested? CI Does this PR introduce any user-facing changes? ☑︎ No. You can skip the rest of this section. ☐ Yes. Make sure to explain your proposed changes and call out the behavior change. linkedin/venice ✅ All checks have passed 30/30 successful checks

1 new commit pushed to

<https://github.com/linkedin/venice/tree/main|main>

by xunyin8

<https://github.com/linkedin/venice/commit/f21b8f82b6466362ef861e720ac9f1a32f9497fd|f21b8f82>

- [fast-client] Wrong value schema id used when handling multi-get response in FC (#792) linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice

1 new commit pushed to

<https://github.com/linkedin/venice/tree/main|main>

by m-nagarajan

<https://github.com/linkedin/venice/commit/6a1aaca32292d95d382f57ffff3aba4c495533c6|6a1aaca3>

- [fc][test] FC warmup part 2: Warm up H2 conns to all server instances during metadata update (#709) linkedin/venice

#709 [fc][test] FC warmup part 2: Warm up H2 conns to all server instances during metadata update Pull request opened by m-nagarajan Summary • After the initial metadata refresh, noticed spikes in latency at the very beginning both in prod and cert as well as leading to potential flaky integration tests. To make the warmup more complete, adding a method to warmup the H2 conns to all the server instances. As we are not trying to validate the metadata here but just to warmup conns beforehand, warmup is on best effort basis for now. To improve the long tail and potentially further improve the client startup speed by not waiting till the timeout for all the conns to be warmed up, more fine-grained logic wrt partitions, replicas or warmup success rate can be added which might succeed faster than waiting for all conns. • Marked

testFastClientWithLongTailRetry

as flaky as the retry mechanism in integration tests are non-deterministic leading to flaky tests • Added a config

metadataConnWarmupTimeoutInSeconds

defaulting to 20 seconds. This dictates how long to wait for the h2 connection warmup. How was this PR tested? GH CI (added new unit tests) Does this PR introduce any user-facing changes? ☑︎ No. You can skip the rest of this section. ☐ Yes. Make sure to explain your proposed changes and call out the behavior change. linkedin/venice ✅ All checks have passed 30/30 successful checks

Deployment to github-pages by github-pages[bot] linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice

1 new commit pushed to

<https://github.com/linkedin/venice/tree/main|main>

by gaojieliu

<https://github.com/linkedin/venice/commit/87dda6b2fa78389ce3845b84397f26c02d6f8deb|87dda6b2>

- [server] Add a new option to allocate dedicated consumer pool for leader replicas of AA/WC stores (#794) linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice

#795 [alpini][router] Repaired the Alpini build Pull request opened by FelixGV The Alpini build got broken by the Netty bump in 9163931. This does not seem to affect the main code, which has been running in production successfully, but some of the tests fail due to this. In addition, some tests are failing due to subtle differences between JDK versions. This commit is a series of changes to fix all of that. • Tweaked TestRequestLogHandler so that it works in all JDK versions. • Skipped TestHeaderUtils::testRandomWeakUUID on JDK 17 since it does not work. • Created a TestNettyUtil with a function to detect when Epoll is not available (as is the case on mac) and throw a SkipException so that tests don't fail. • Deleted several unused classes that were broken by the Netty bump, including: ContentCompressor, HttpClientResponseHandler, Http2ClientResponseHandler and Http2AwareChannelPoolFactory, as well as their accompanying tests. • Also added a dependency to org.bouncycastle:bcpkix-jdk15on which is necessary in JDK17. Misc: • Added JDK 8 and 11 to AlpiniUnitTests, like we do for Venice unit tests. They will still run only when the Alpini code changes. How was this PR tested? CI. Does this PR introduce any user-facing changes? ☑︎ No. You can skip the rest of this section. ☐ Yes. Make sure to explain your proposed changes and call out the behavior change. linkedin/venice ✅ All checks have passed 30/30 successful checks

1 new commit pushed to

<https://github.com/linkedin/venice/tree/main|main>

by FelixGV

<https://github.com/linkedin/venice/commit/8fc7a548cb6400306364e954ded20fda78f4822f|8fc7a548>

- [alpini][router] Repaired the Alpini build (#795) linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice

Deployment to github-pages by github-pages[bot] linkedin/venice