yandrey321 opened a new pull request, #10594: URL: https://github.com/apache/ozone/pull/10594
Before the fix the 6-argument constructor called fetchBlocks(), which issues a lookupKey RPC to OM when keyInfo is null. Because this.keyInfo is not assigned until after the 6-arg constructor returns, keyInfo was always null inside fetchBlocks(), so the RPC was always issued — even when the caller already had OmKeyInfo in hand. The fix reverses the chain: the 6-arg constructor delegates to the 7-arg with null, and the 7-arg constructor does the full initialization, assigning this.keyInfo before calling fetchBlocks(). getChunkInfos() builds a standalone Pipeline containing only the selected nodes (data replica index 1 and all parity nodes). The old code used pipeline.toBuilder(), which copies the full EC nodeStatus map (all 5 or 9 nodes). When setNodes() was then called with the smaller selected-node list, Pipeline.Builder detected the size mismatch and replaced the pipeline ID with PipelineID.randomId() — calling SecureRandom.nextBytes() on every file, even though setId(deterministicId) was not called at all in the old code. Because the pipeline ID was random per file, XceiverClientManager could never reuse a cached gRPC connection: every file opened a new connection regardless of whether it hit the same physical datanodes. The fix does two things: a) Compute a deterministic pipeline ID from the sorted UUIDs of the selected nodes b) Switch from toBuilder() to Pipeline.newBuilder() so that nodeStatus starts with null. Pipeline.Builder.setNodes() only calls PipelineID.randomId() when nodeStatus != null and the node count changes. With newBuilder() nodeStatus is always null, so the random replacement never triggers. ## What is the link to the Apache JIRA https://issues.apache.org/jira/browse/HDDS-15643 ## How was this patch tested? 1. Run existing unit and integration tests 2. Run the benchmark FileChecksumBenchmark, 5 threads, 10 s warmup + 20 s measurement per combination. Two configurations (RS-3-2, RS-6-3) × three simulated OM latencies (0ms / 5 ms / 10 ms). The test is implemented in a way to limit test hit by 75% and intentionally force hit misses. Config | Latency | Before | After | Ratio -- | -- | -- | -- | -- RS-3-2 | 0ms | 62,203 | 80,691 | 1.30× RS-3-2 | 5ms | 405 | 637 | 1.57× RS-3-2 | 10ms | 204 | 416 | 2.04× RS-6-3 | 0ms | 42,613 | 53,837 | 1.26× RS-6-3 | 5ms | 348 | 812 | 2.34× RS-6-3 | 10ms | 184 | 416 | 2.26× The gain is largest at higher latencies because connection reuse (Fix 2) saves one full RPC round-trip per file. At 0 ms the dominant gain is Fix 1 (halving OM calls). The OM/file counter confirms 2.00 → 1.00 for all rows; CacheHit% confirms 0% → 74-75% for all rows. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
