Junping Du commented on YARN-3391:

bq. I make use of Sangjin's previous comments to add some inline code comments 
about their definitions in TimelineCollectorContext.
I would expect the definition can show up in Javadoc of related methods in 
TimelineCollectorContext. This sounds like a little nitpick, but the key 
differences between inline comments and javadoc is if developer only use jar 
instead of source code, they can still read these key definitions and use it 
correctly (by IDE hint or generated Javadoc). So in general, I think we should 
use as much javadoc comments instead of inline comments for public APIs. 

+    // Sanity check for flow run
+    try {
+      for (String tag : submissionContext.getApplicationTags()) {
+        if (tag.startsWith(TimelineUtils.FLOW_RUN_TAG_PREFIX + ":") ||
+            tag.startsWith(
+                TimelineUtils.FLOW_RUN_TAG_PREFIX.toLowerCase() + ":")) {
+          String value =
+              tag.substring(TimelineUtils.FLOW_RUN_TAG_PREFIX.length() + 1);
+          Long.valueOf(value);
+        }
+      }
+    } catch (NumberFormatException e) {
+      LOG.warn("Invalid to flow run.", e);
+      RMAuditLogger.logFailure(user, AuditConstants.SUBMIT_APP_REQUEST,
+          e.getMessage(), "ClientRMService",
+          "Exception in submitting application", applicationId);
+      throw RPCUtil.getRemoteException(e);
+    }
We should add more info to LOG.warn messages, at least to tell user flow run 
should be numeric. In addition, do we need to check negative value for flow run 
here? If not, why we are accepting negative long value but rejecting other 
characters than number?

> Clearly define flow ID/ flow run / flow version in API and storage
> ------------------------------------------------------------------
>                 Key: YARN-3391
>                 URL: https://issues.apache.org/jira/browse/YARN-3391
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Zhijie Shen
>            Assignee: Zhijie Shen
>         Attachments: YARN-3391.1.patch, YARN-3391.2.patch, YARN-3391.3.patch
> To continue the discussion in YARN-3040, let's figure out the best way to 
> describe the flow.
> Some key issues that we need to conclude on:
> - How do we include the flow version in the context so that it gets passed 
> into the collector and to the storage eventually?
> - Flow run id should be a number as opposed to a generic string?
> - Default behavior for the flow run id if it is missing (i.e. client did not 
> set it)
> - How do we handle flow attributes in case of nested levels of flows?

This message was sent by Atlassian JIRA

Reply via email to