Kacper Bielecki
09/05/2025, 9:29 AMKacper Bielecki
09/05/2025, 9:30 AMCaused by: org.rocksdb.RocksDBException: While lock file: /opt/venice/rocksdb/rocksdb/client-id-to-email-hash_v26/client-id-to-email-hash_v26_1000000000/LOCK: Resource temporarily unavailable
I am attaching VPJ, leader controler and one of the venice-server logs. It seems that venice-server tries to open the metadata database from multiple threads and the locking failures are not retried.
Is it a known issue? Are we doing anything wrong? 🤔Felix GV
10/21/2025, 2:09 PMFelix GV
10/21/2025, 4:15 PMAmre Shakim
10/23/2025, 10:53 PMFelix GV
11/19/2025, 5:46 PMGaojie Liu
11/19/2025, 5:58 PMFelix GV
11/19/2025, 7:00 PMZac Policzer
11/19/2025, 7:39 PMZac Policzer
11/19/2025, 7:40 PMZac Policzer
11/19/2025, 7:49 PMKoorous Vargha
12/08/2025, 5:52 PMPavan
12/09/2025, 4:53 AMcom.linkedin.davinci.store.rocksdb considered the canonical implementation for local storage across both the Venice Server and the Da Vinci Client?Sushant Mane
02/13/2026, 8:57 PMZac Policzer
02/15/2026, 3:26 AMKoorous Vargha
02/17/2026, 5:00 PMZac Policzer
03/02/2026, 2:05 AMCraig Alfieri
03/11/2026, 9:01 PMDmytro Prokhorenkov
03/19/2026, 5:25 PMZac Policzer
03/25/2026, 9:40 PMSergey Makagonov
03/30/2026, 4:34 PM1:00pm VPJ1 pushes purchase_count = 3
1:10pm RT update: purchase_count = 4
1:15pm RT update: purchase_count = 5
1:30pm RT update: purchase_count = 6
1:35pm VPJ2 pushes, but batch data lags by 15min: purchase_count = 5
As VPJ2's new version is being built, RT events from 110 130 are also being applied to it. But DCR resolves conflicts by timestamp:
• Batch sets purchase_count = 5 (with timestamp 1:35pm)
• RT event from 1:30pm (purchase_count = 6) has an earlier timestamp
• Timestamp-based resolution: batch wins. Value regresses to 5.
So far, my understanding is that achieving good consistency with Batch + RT updates is possible only if RT updates separate set of fields through write-compute.
Am I missing something? I put up a doc on Venice Hybrid store considerations as a reference.
cc @Hubert Puszklewicz @Amre ShakimFelix GV
04/01/2026, 9:21 PMFelix GV
04/02/2026, 11:11 AMZac Policzer
04/21/2026, 8:45 PMSergey Makagonov
05/05/2026, 4:00 PMZac Policzer
05/19/2026, 4:21 PMFelix GV
06/07/2026, 10:57 PMSergey Makagonov
06/12/2026, 8:47 PM[lo, hi] range) as a first-class read API on top of it?
What we understand about why it's not there today:
- Stores are hash-partitioned on the full key, so logically-adjacent keys scatter across partitions. There's no bounded home for a range, unlike point/batch-get.
- Keys are opaque (Avro-serialized) bytes, and Avro's encoding isn't bytewise-order-preserving, so even a within-partition RocksDB iterator wouldn't map to a logical range.
- A general unbounded scan would break the predictable-tail-latency / RCU quota model.
Curious whether it's ever been discussed or prototyped, and if there's a design doc or RFC. If it was ruled out, I'd love to understand the main reasons. Thanks!
cc @Felix GV @Zac Policzer @Koorous Vargha
@Hubert Puszklewicz @Amre Shakim fyiKoorous Vargha
07/20/2026, 4:00 PM