pithecuse527 opened a new pull request, #3682:
URL: https://github.com/apache/celeborn/pull/3682
<!--
Thanks for sending a pull request! Here are some tips for you:
- Make sure the PR title start w/ a JIRA ticket, e.g. '[CELEBORN-XXXX]
Your PR title ...'.
- Be sure to keep the PR description updated to reflect all changes.
- Please write your PR title to summarize what this PR proposes.
- If possible, provide a concise example to reproduce the issue for a
faster review.
-->
### What changes were proposed in this pull request?
This PR fixes JVMQuake time accounting by preserving threshold config values
as milliseconds and converting JVMStat GC timer tick deltas to nanoseconds
before updating the token bucket.
### Why are the changes needed?
JVMQuake thresholds were parsed as milliseconds but wrapped as microseconds,
making values such as 60s behave like 60ms. JVMStat GC timer metrics are
reported in ticks, so using them directly can misaccount GC time.
### Does this PR resolve a correctness bug?
<!-- Yes/No. (Note: If yes, committer will add `correctness` label to
current pull request). -->
Yes
### Does this PR introduce _any_ user-facing change?
Yes
### How was this patch tested?
1. UT - Added unit coverage for JVMQuake threshold parsing and JVMStat
tick-to-nanosecond conversion.
2. E2E - Verified the behavior in a kubernetes cluster with JVMQuake enabled
using dump.threshold=30s, kill.threshold=60s, and runtimeWeight=0. For the
original image, repeated GC caused the worker to exit early, and the logs
showed killThreshold: 60000000, meaning the configured 60s threshold was
effectively treated as 60ms. With the patched image and the same
configuration/GC trigger, the worker stayed Ready and the restart count
remained 0, confirming that the threshold unit conversion was corrected.
--
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]
