github-actions[bot] commented on code in PR #64734:
URL: https://github.com/apache/doris/pull/64734#discussion_r3459320733
##########
be/src/cloud/cloud_warm_up_manager.cpp:
##########
@@ -494,11 +503,14 @@ Status CloudWarmUpManager::set_event(int64_t job_id,
TWarmUpEventType::type even
Status st = Status::OK();
if (event == TWarmUpEventType::type::LOAD) {
if (clear) {
- _tablet_replica_cache.erase(job_id);
+ if (_tablet_replica_cache.erase(job_id) > 0) {
+ g_file_cache_warm_up_job_num << -1;
+ }
_event_driven_filters.erase(job_id);
Review Comment:
This event-driven increment also needs to be balanced in the lazy
cancellation path. When FE later reports `TStatusCode.CANCELLED` from
`getTabletReplicaInfos` for a removed/done warm-up job, `get_replica_info()`
records the job in `cancelled_jobs` and erases `_tablet_replica_cache` at line
647, but that erase does not decrement `g_file_cache_warm_up_job_num`. The
existing cancel-passive/expired flows rely on that lazy cleanup when CLEAR_JOB
is missed, so after the cache entry is removed the new "jobs currently held in
this BE's memory" bvar can stay at 1 even though the job is no longer held.
Please decrement the metric when that erase actually removes an entry, and keep
the event filter cleanup consistent with the explicit clear path.
--
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]
