JeetKunDoug commented on code in PR #192:
URL: https://github.com/apache/cassandra-sidecar/pull/192#discussion_r1955313085
##########
server/src/main/java/org/apache/cassandra/sidecar/tasks/PeriodicTaskExecutor.java:
##########
@@ -329,15 +343,18 @@ public String toString()
}
}
- @VisibleForTesting
- Map<PeriodicTaskKey, Long> timerIds()
+ enum Result
{
- return timerIds;
+ /**
+ * Tells the run completion handler whether task is rescheduled.
+ * If it is rescheduled, the delay is adjusted to the initial delay of
the task
+ */
+ RESCHEDULED
Review Comment:
Can we have a Result that _doesn't_ mean RESCHEDULED, like COMPLETED? The
fact that we call`Promise#tryComplete` with either RESCHEDULED or nothing at
all (essentially, `null`) seems really odd, even if we never really check for
COMPLETED.
##########
server/src/main/java/org/apache/cassandra/sidecar/tasks/PeriodicTaskExecutor.java:
##########
@@ -130,22 +147,33 @@ private void schedule(PeriodicTaskKey key, long
priorExecDurationMillis, long de
*/
private void executeAndScheduleNext(PeriodicTaskKey key, long execCount)
{
+ Promise<Void> runPromise = Promise.promise();
+ if (activeRuns.computeIfAbsent(key, k -> runPromise.future()) !=
runPromise)
+ {
+ LOGGER.debug("already active. task='{}' execCount={}", key,
execCount);
+ return;
+ }
long startTime = System.nanoTime();
- internalPool.<Void>executeBlocking(promise -> executeInternal(promise,
key, execCount), false)
- .onComplete(ignored -> {
- LOGGER.debug("Task run finishes. task='{}'
execCount={}", key, execCount);
- // schedule the next run iff the task is not killed
- if (poisonPilledTasks.remove(key))
+ internalPool.<Result>executeBlocking(promise ->
executeInternal(promise, key, execCount), false)
+ .onComplete(outcome -> {
+ LOGGER.debug("Task run finishes. task='{}' outcome={}
execCount={}", key, outcome, execCount);
+ runPromise.complete(); // mark the completion,
regardless of the result from last run
+ activeRuns.remove(key);
+
+ DurationSpec delay;
+ long priorExecutionDurationMillis;
+ if (outcome.result() == Result.RESCHEDULED)
+ {
+ priorExecutionDurationMillis = 0;
+ delay = key.task.initialDelay();
Review Comment:
Why do we always use the `initialDelay` here? What if the task has run 20
times already - do we still want to use `initialDelay`? Can we use `execCount`
here to decide which delay to use?
--
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]
