jihoonson opened a new issue #5523: URL: https://github.com/apache/druid/issues/5523
Today, `TaskStatus` is widely used in many places, e.g., 1) to return the result of task processing from peons to overlords, 2) to keep track of running tasks in overlords, 3) as a return value of overlord APIs to get the current task status, and so on. This has some issue like below. - Lack of information in `TaskStatus`: `TaskStatus` is a simple POJO including a `taskId`, `taskState`, and `duration`. However, usually we need much more stuffs to check the status of tasks like `taskType`, `createdTime`, `startTime`, `endTime`, and `location`. - `TaskRunnerWorkItem` vs `TaskStatus`: `TaskRunnerWorkItem` and its subclasses are another form to represent a task status. I think they are needed because of the above issue. - `TaskStatusPlus` vs `TaskStatus`: `TaskStatusPlus` is introduced because of the lack of information issue. And now, some overlord APIs return `TaskStatusPlus` while others return `TaskStatus` (actually `TaskStatusResponse`). It breaks consistency. - Backward compatibility: since `TaskStatus` is used in some public overlord APIs, it's difficult to change it while keeping backward compatibility. - `TaskStatus` locates in `indexing-service` module, but it is used by coordinators as well. This requires to make a copy in `server` module and keep them synchronized until those modules are merged. Using many classes makes difficult for us to understand and maintain the code. We can simplify this by merging some classes into one and decide which ones are exposed as the public API or not. ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
