DanielLeens commented on issue #12058: URL: https://github.com/apache/seatunnel/issues/12058#issuecomment-5635786970
The baseline evidence is sufficient to classify this as write-through wait variance, not a GC or CPU-hot-`hsync` conclusion. The flame stacks and the low CPU share for `hsync` consistently show the benchmark thread blocked through Hazelcast invocation completion while the WAL sync runs on the storage path. That closes the root-cause step, but it does not yet authorize a production optimization. The next experiment must change one variable only and preserve the current write-through durability contract; changing MapStore mode, disabling persistence, or merely hiding the wait would invalidate this benchmark. Use the same machine, JDK, initial data, workload and profiler set, retain the raw per-fork diagnostics from #12248, and show that the original wait hotspot shrinks alongside the score/error/CV change. Please post the exact first candidate and its expected semantic invariants before opening an optimization PR. A movement in score alone will not establish a safe fix. -- 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]
