Zhijie Shen commented on YARN-2581:

Basically the approach in this patch is to embed LogAggregationContext into 
ContainerTokenIdentifier, which will be passed to AM when allocating 
containers. Afterwards, AM can use it to start a container on NM. The merit is 
that LogAggregationContext is automatically forwarded to NM without app user's 
involvement. The approach makes sense to me.

1. The old constructor call the new one? Same for ApplicationInitEvent and 
   public ContainerTokenIdentifier(ContainerId containerID,
       String hostName, String appSubmitter, Resource r, long expiryTimeStamp,
@@ -74,6 +78,22 @@ public ContainerTokenIdentifier(ContainerId containerID,
     this.creationTime = creationTime;

2. Exchange two params? First should be expected, and the second should be 
+    assertEquals(recovered.getRollingIntervalSeconds(),
+      logAggregationContext.getRollingIntervalSeconds());

3. No need to remember appSubmissionContext, but remember LogAggregationContext 
+  private ApplicationSubmissionContext appSubmissionContext = null;

> NMs need to find a way to get LogAggregationContext
> ---------------------------------------------------
>                 Key: YARN-2581
>                 URL: https://issues.apache.org/jira/browse/YARN-2581
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: nodemanager, resourcemanager
>            Reporter: Xuan Gong
>            Assignee: Xuan Gong
>         Attachments: YARN-2581.1.patch, YARN-2581.2.patch
> After YARN-2569, we have LogAggregationContext for application in 
> ApplicationSubmissionContext. NMs need to find a way to get this information.
> We have this requirement: For all containers in the same application should 
> honor the same LogAggregationContext.

This message was sent by Atlassian JIRA

Reply via email to