'shutdownAllTasks' API for a dataSource#6185
Conversation
Change-Id: I30d14390457d39e0427d23a48f4f224223dc5777
|
|
||
| Shuts down a task. | ||
|
|
||
| * `druid/indexer/v1/task/{dataSource}/shutdown` |
There was a problem hiding this comment.
This namespace collides with {taskId}. It's not likely that anyone will actually create a task with the same name as a datasource, but you never know, so let's use a different URL here. How about: /druid/indexer/v1/dataSource/{dataSource}/shutdownAllTasks
| } | ||
|
|
||
| if (!ownTask) { | ||
| return Response.status(Response.Status.BAD_REQUEST) |
There was a problem hiding this comment.
IMO, we should return OK in this case, because that makes the kill-all operation idempotent. It's a good property to have, especially in something that might be done "just in case" when removing a datasource.
There was a problem hiding this comment.
If so, I'll remove the ownTask variable and return Response.ok(ImmutableMap.of("dataSource", dataSource)).build() for all case. Is that OK?
There was a problem hiding this comment.
That sounds good to me… thanks!
Change-Id: Ib463f31ee2c4cb168cf2697f149be845b57c42e5
| taskQueue.shutdown(task.getId()); | ||
| ownTask = true; | ||
| } | ||
| } |
There was a problem hiding this comment.
You can also use this API getActiveTaskInfo(@Nullable String dataSource) which takes a dataSource as argument and filters at the DB query time, so you will only get the matching dataSource active tasks. So like below. It might be efficient as you don't have to compare every task's dataSource in the for loop.
final List<TaskInfo<Task, TaskStatus>> tasks = taskStorageQueryAdapter.getActiveTaskInfo(dataSource);
for (final TaskInfo<Task, TaskStatus> task : tasks) {
taskQueue.shutdown(task.getId());
}```
Change-Id: I50a8dcd44dd9d36c9ecbfa78e103eb9bff32eab9
| public Response apply(TaskQueue taskQueue) | ||
| { | ||
| final List<TaskInfo<Task, TaskStatus>> tasks = taskStorageQueryAdapter.getActiveTaskInfo(dataSource); | ||
| for (final TaskInfo<Task, TaskStatus> task : tasks) { |
There was a problem hiding this comment.
Maybe tasks.parallelStream().forEach(t -> taskQueue.shutdown(t.getId())) will be better.
There was a problem hiding this comment.
I do not think so, taskQueue.shutdown is a synchronized operation. Use parallelStream has no performance improvement.
There was a problem hiding this comment.
Yes, you are right. Even if ReentrantLock is good at handling with concurrent scenes, we should not try to use parallelStream here. I didn't notice it. My fault. Forget it, what do you think of converting it into a more functional programming style, such as tasks.forEach(t -> taskQueue.shutdown(t.getId()))?
There was a problem hiding this comment.
I think there is no need. Other for loop code in class OverlordResource are not functional programming style. Coding style should keep consistency.
There was a problem hiding this comment.
Agree that it's good to be consistent within a file, and the rest of this file is totally down with for loops.
|
have restarted the failing travis. |
Try to fix #6115