SEZ9 commented on issue #12058: URL: https://github.com/apache/seatunnel/issues/12058#issuecomment-5691025295
@Rangsh thanks for running the requested experiment and for posting the gist (`3c3f49c79c6583a1ca954b7d47a49627`) — that answers the "share the raw summaries" question, and keeping the raw `.jfr` local is fine. On the results themselves: I agree with your verdict. The OPI=100 attempt-04 correlation (Pearson 0.65 / Spearman 0.84, fork 2 spike co-located with the ~950 µs park window) is consistent with the earlier narrow conclusion that the `InvocationFuture` park is material on the timed path. The OPI=1 run, with the 5385 µs spike carrying only ~478 µs of park, is a useful negative: it shows park is not the sole spike source, so nothing here justifies a production change. The historical ~32% / ~393 µs day is still unreproduced (15.6% is the best you got), so that remains open. Same caveat as before, and I'd like it stated explicitly in `NOISY-ALIGN-REPORT.md`: everything here is against the `file:///` harness on `38a37104e`, so it rules things in or out only for that local setup and should not be read as a statement about a real HDFS/DFS client. Please don't generalize the park/no-park attribution beyond that. Remaining asks: 1. Add a one-line scope note to the gist report that the conclusions are `file:///`-only. 2. Confirm the diagnostic system property that skipped the TearDown durable reload/validate in run O is fully removed from the fixture (you said "restored afterward" — a quick confirmation is enough). 3. Keep production code unchanged; `#12081` stays Related-only and does not close this issue. If the historical high-CV day ever reappears, capture it with the same baseline and JFR settings so it's directly comparable to attempt-04. <!-- streview-comment:1076 --> -- 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]
