rohangarg commented on code in PR #13476:
URL: https://github.com/apache/druid/pull/13476#discussion_r1044377655
##########
indexing-service/src/main/java/org/apache/druid/indexing/worker/executor/ExecutorLifecycle.java:
##########
@@ -108,7 +108,7 @@ public void start() throws InterruptedException
// pod twice, no need to lock.
if (taskExecutorConfig.isParentStreamDefined()) {
// Avoid running the same task twice on the same machine by locking the
task base directory.
- final File taskLockFile = taskConfig.getTaskLockFile(task.getId());
+ final File taskLockFile =
Preconditions.checkNotNull(taskExecutorConfig.getLockFile(), "lockFile");
Review Comment:
nit : `lockfile is null`
##########
indexing-service/src/main/java/org/apache/druid/indexing/worker/executor/ExecutorLifecycleConfig.java:
##########
@@ -39,6 +39,10 @@
@NotNull
private File statusFile = null;
+ @JsonProperty
+ @NotNull
Review Comment:
This seems like a weird pattern - since we're not actually enforcing
non-null check anywhere
##########
indexing-service/src/main/java/org/apache/druid/indexing/common/config/TaskConfig.java:
##########
@@ -182,6 +197,16 @@ public TaskConfig(
}
log.debug("Batch processing mode:[%s]", this.batchProcessingMode);
this.storeEmptyColumns = storeEmptyColumns == null ?
DEFAULT_STORE_EMPTY_COLUMNS : storeEmptyColumns;
+
+ this.baseTaskDir = baseTaskDir;
+ if (CollectionUtils.isNullOrEmpty(baseTaskDirPaths)) {
Review Comment:
While it is done for javaOpts and javaOptsArray as well, the problem I feel
with this is that there is an implicit precedence order amongst the configs
which the user would have to remember. Here, it would be :
1. if `dirPaths` property is present and non-empty, then it takes precedence
over `dirPath` property
2. otherwise, `dirPath` property takes precedence
My personal opinion is that it is better to raise exception in case of
conflict in configs - but I'd be ok to have auto merge if that helps in some
user case.
##########
indexing-service/src/main/java/org/apache/druid/indexing/overlord/BaseRestorableTaskRunner.java:
##########
@@ -173,24 +184,32 @@ public Collection<TaskRunnerWorkItem> getKnownTasks()
@GuardedBy("tasks")
protected void saveRunningTasks()
{
- final File restoreFile = getRestoreFile();
- final List<String> theTasks = new ArrayList<>();
+ final Map<File, List<String>> theTasks = new HashMap<>();
for (TaskRunnerWorkItem forkingTaskRunnerWorkItem : tasks.values()) {
- theTasks.add(forkingTaskRunnerWorkItem.getTaskId());
+ final String taskId = forkingTaskRunnerWorkItem.getTaskId();
+ final File restoreFile = getRestoreFile(taskId);
+ theTasks.computeIfAbsent(restoreFile, k -> new ArrayList<>())
+ .add(taskId);
}
- try {
- Files.createParentDirs(restoreFile);
- jsonMapper.writeValue(restoreFile, new TaskRestoreInfo(theTasks));
- }
- catch (Exception e) {
- LOG.warn(e, "Failed to save tasks to restore file[%s]. Skipping this
save.", restoreFile);
+ for (Map.Entry<File, List<String>> entry : theTasks.entrySet()) {
+ final File restoreFile = entry.getKey();
+ final TaskRestoreInfo taskRestoreInfo = new
TaskRestoreInfo(entry.getValue());
+ try {
+ Files.createParentDirs(restoreFile);
+ jsonMapper.writeValue(restoreFile, taskRestoreInfo);
+ LOG.info("Save restore file at [%s] for tasks [%s]",
+ restoreFile.getAbsoluteFile(),
Arrays.toString(theTasks.get(restoreFile).toArray()));
+ }
+ catch (Exception e) {
+ LOG.warn(e, "Failed to save tasks to restore file[%s]. Skipping this
save.", restoreFile);
+ }
}
}
- protected File getRestoreFile()
+ private File getRestoreFile(String taskId)
{
- return new File(taskConfig.getBaseTaskDir(), TASK_RESTORE_FILENAME);
+ return new File(taskConfig.getOrSelectTaskDir(taskId),
TASK_RESTORE_FILENAME);
Review Comment:
I think `getOrSelectTaskDir` should be private method and outside users
should only use `getTaskDir` - there are some more occurrences of
`getOrSelectTaskDir` which can be replaced.
--
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]
