wombatu-kun commented on code in PR #19004:
URL: https://github.com/apache/hudi/pull/19004#discussion_r3411169670
##########
hudi-trino-plugin/src/test/java/io/trino/plugin/hudi/TestHudiAlluxioCacheFileOperations.java:
##########
@@ -87,12 +87,6 @@ public void testSelectWithFilter()
assertFileSystemAccesses(
query,
ImmutableMultiset.<FileOperation>builder()
- .addCopies(new FileOperation("Alluxio.readCached",
DATA), 2)
Review Comment:
Done 189f4e0b668c - added `testReadsServedFromAlluxioCache`, which warms the
cache and then asserts at least one `Alluxio.readCached` span. It is a lower
bound rather than an exact count, so it is immune to the off-by-N leak, and it
is wrapped in `assertEventually` to tolerate the asynchronous cache write. It
passed 8 consecutive runs locally.
On running them sequentially or independently: these three classes already
run isolated and single-threaded. Each is annotated `@Execution(SAME_THREAD)`
and they share `@ResourceLock("HUDI_CACHE_SYSTEM")`, so they never run
concurrently with one another and never interleave their own methods. The flake
is not a race between tests. The spans leak because Trino resets the span
exporter at the start of each `executeWithPlan`, while Hudi's background pools
(split loading, partition listing, index support) and Alluxio's asynchronous
cache population keep emitting spans after the synchronous query has returned,
so those spans land in the next query's measurement window even on a single
thread. That is why the earlier span-stability poll (#18766) and disabling the
stats refresh (#18995) did not stop it, and why the remaining exact `Alluxio.*`
counts cannot be made deterministic by ordering alone.
--
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]
