kfaraz commented on code in PR #16041:
URL: https://github.com/apache/druid/pull/16041#discussion_r1513861858
##########
indexing-service/src/main/java/org/apache/druid/indexing/common/task/Task.java:
##########
@@ -134,6 +134,23 @@ default int getPriority()
*/
String getType();
+ /**
+ * Provides a default implementation for obtaining a task's label. This
label is intended
+ * to serve as a descriptive identifier for the task's purpose or type,
which can be utilized
+ * for more nuanced task management, monitoring, and logging activities.
+ *
+ * By default, this method returns the task type obtained from {@link
#getType()},
+ * reflecting the basic categorization of the task.
+ *
+ * @return A string representing the task's label, which by default is the
task type.
+ * Override this method to specify more granular labels tailored to
the task's
+ * specific purpose or operational characteristics.
+ */
+ default String getLabel()
+ {
+ return getType();
+ }
Review Comment:
@arunramani , if we want to have a generic `Map<String, Object>`, wouldn't
the existing task context suffice for that?
As @suneet-s suggests, an extensible labeling mechanism is worth a thought.
For simpler use cases though, we could simply try to add a new task context
parameter as it is already a flexible structure that allows Druid operators
complete control over their tasks. It has the added benefit of not having to
educate operators on new mechanisms.
--
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]
