github-actions[bot] commented on code in PR #62384:
URL: https://github.com/apache/doris/pull/62384#discussion_r3340141208
##########
fe/fe-core/src/main/java/org/apache/doris/cloud/CacheHotspotManager.java:
##########
@@ -781,6 +962,31 @@ public Map<Long, List<Tablet>>
warmUpNewClusterByTable(long jobId, String dstClu
}
public long createJob(WarmUpClusterCommand stmt) throws AnalysisException {
+ OncePendingJobKey oncePendingJobKey = buildOncePendingJobKey(stmt);
+ if (oncePendingJobKey != null) {
+ RefCountedPendingCreateLock createLock =
retainOncePendingCreateLock(oncePendingJobKey);
+ createLock.lock();
+ try {
+ CloudWarmUpJob existingPendingJob =
findExistingPendingOnceJob(oncePendingJobKey);
+ if (existingPendingJob != null) {
Review Comment:
This reuse decision is racy with the scheduler/cancel paths because the new
per-key lock is only taken by `createJob()`. `findExistingPendingOnceJob()`
observes a mutable `CloudWarmUpJob` as `PENDING`, but `runCloudWarmUpJob()` can
submit that same job and `CloudWarmUpJob.runPendingJob()` can change it to
`RUNNING` immediately after this line; `cancel()` can similarly move it to a
final state. In that interleaving the new CLUSTER once request returns the old
job id at line 978 instead of creating the new pending job that the code
intentionally allows when only a running/finished job exists, so the user's
requested warm-up is dropped. Please make the pending-state check and reuse
atomic with the state transition path, or revalidate the job is still pending
under the same synchronization before returning the existing id.
--
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]
