habiibullahm commented on issue #4203: URL: https://github.com/apache/hertzbeat/issues/4203#issuecomment-5153076457
Hi @hengyuss @tomsun28 — I'd like to help with this if it's still available. I looked at `CommonDispatcher`: - In-flight collects are tracked in `metricsTimeoutMonitorMap` with `DURATION_TIME = 240_000L` (4 minutes) - `monitorCollectTaskTimeout` removes the map entry and calls `dispatchCollectData` with a `TIMEOUT` payload - When the real `MetricsCollect` finishes later, it calls `dispatchCollectData` again; `remove(monitorKey)` returns null so metrics recording is skipped, but `sendMetricsData` / cyclic re-schedule (and next-level scheduling) can still run — that matches the duplicate-dispatch behavior Proposed approach: 1. Make `dispatchCollectData` once-wins (e.g. early-return on completion when the monitor entry was already removed by timeout, with care for subtask/prometheus keys), and/or cancel/mark the in-flight collect on timeout so `MetricsCollect.fastFailed()` stops the late path 2. Add a regression test: timeout fires, then late success → assert `dispatchCollectData` side effects happen only once Quick questions before I open a PR: - @hengyuss you noted “i will fix it” — are you still working on this? Does open PR #4196 (for #4194) also intend to cover #4203, or is that separate? - If this is free, is the once-wins / early-return approach acceptable? Happy to take it if you’re not actively working on it. Thanks! -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
