[ 
https://issues.apache.org/jira/browse/APEXCORE-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15255627#comment-15255627
 ] 

ASF GitHub Bot commented on APEXCORE-439:
-----------------------------------------

Github user PramodSSImmaneni commented on a diff in the pull request:

    https://github.com/apache/incubator-apex-core/pull/314#discussion_r60846619
  
    --- Diff: 
engine/src/main/java/com/datatorrent/stram/plan/physical/PhysicalPlan.java ---
    @@ -979,6 +998,14 @@ public void deployChanges() {
         this.undeployOpers.removeAll(newOpers.keySet());
    --- End diff --
    
    @tweise The getDependents also includes the operators in the argument set, 
since they are new we don't want to undeploy them. So it should be this
    
    Set<PTOperator> ndeps = getDependents(newOpers.keySet());
    ndeps.removeAll(newOpers.keySet());
    this.undeployOpers.addAll(ndeps);
    
    As you pointed out ndeps doesn't have to be added to deployOpers as it is 
already being done in the next line.
    
    I had a line in there 
    ndeps.removeAll(this.undeployOpers);
    to ensure that operators that are already scheduled to be undeployed 
(removed completely) don't get re-deployed because of this but on further 
thought this probably is not required because if some operators are already 
going to be undeployed they will not be in the dependency chain for newly 
deployable operators, is that assumption valid?


> After dynamic repartition application appears blocked
> -----------------------------------------------------
>
>                 Key: APEXCORE-439
>                 URL: https://issues.apache.org/jira/browse/APEXCORE-439
>             Project: Apache Apex Core
>          Issue Type: Bug
>    Affects Versions: 3.3.0
>            Reporter: Munagala V. Ramanath
>            Assignee: Munagala V. Ramanath
>
> When a file input operator (subclass of AbstractFileInputOperator) is 
> dynamically repartitioned, some downstream unifiers are not identified as 
> needing to be redeployed causing the window id to not advance and all 
> downstream operators to be killed and restarted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to