[
https://issues.apache.org/jira/browse/YARN-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484512#comment-14484512
]
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.
{code}
+ // 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);
+ }
{cide}
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
(v6.3.4#6332)
