yihua opened a new pull request, #20265: URL: https://github.com/apache/hudi/pull/20265
### Describe the issue this Pull Request addresses closes #20264 part of #20257 Every file system view request to the timeline server checks view freshness before and after the handler. Each check builds a filtered copy of the view timeline and SHA-256 hashes every instant, and the check before the handler always runs inside `synchronized (view)`, so all requests for a table serialize on hashing even when the client is in sync. The unconditional lock dates from #8079 (HUDI-5863, 0.13.1), which fixed a data-loss bug by making `sync()` and `reset()` atomic under the view's write lock and, as a simplification, dropped the earlier unlocked pre-check. ### Summary and Changelog - `RequestHandler` keeps, per base path, the view timeline last checked under the monitor with its filtered copy (hashed once) and, when it ends with a clean, the hash before that clean (the #19946 trailing-clean exemption). - A request whose client timeline matches that entry while it is still the view's current timeline (identity check) skips the monitor; anything else takes the existing locked path, which refreshes the entry. - The entry is dropped before `view.sync()` and republished after it, and dropped on refresh-table and `TimelineService.unregisterBasePath`. The post-handler check reuses it, so neither check hashes per request. - New `TestViewFreshnessCheck`: one filter and hash per view timeline under 64 concurrent requests, in-sync clients served while another thread holds the monitor, and requests during a sync waiting until it completes (checked by thread state; fails for both naive lock-free variants). On master, 64 requests hash the timeline 128 times and an in-sync request blocks. ### Impact The freshness check drops from two SHA-256 passes over the active timeline (one under the per-table monitor) to an identity check and a string compare for clients in sync. No API or config change. Local micro-benchmark (mocked view, 2000 active instants, 32 client threads, 3 alternating runs, medians, heavily loaded laptop, not a production number): - commit-only timeline: 1386 to 12592 req/s, p50 17.5 to 1.1 ms - timeline ending in a clean: 743 to 22040 req/s, p50 36 to 0.66 ms Open #20239 changes the locked path of the same method; the two compose but need a manual rebase. ### Risk Level low: a request skips the lock only when the view's current timeline object is the one last validated under the monitor, and that object changes only inside `sync()` (under the monitor) or when the view is recreated (a new object, which fails the identity check). This keeps #8079's guarantee: a request that skips the lock behaves as if it had been checked before any sync that starts after it, as a request that passed the locked check does on master. `TestTimelineViewRefresh` (#19946) passes unchanged. ### Documentation Update none ### Contributor's checklist - [ ] Read through [contributor's guide](https://hudi.apache.org/contribute/how-to-contribute) - [ ] Enough context is provided in the sections above - [ ] Adequate tests were added if applicable -- 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]
