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

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

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

    https://github.com/apache/apex-core/pull/359#discussion_r71744011
  
    --- Diff: 
engine/src/main/java/com/datatorrent/stram/plan/physical/PhysicalPlan.java ---
    @@ -895,8 +895,10 @@ private void redoPartitions(PMapping currentMapping, 
String note)
             addedPartitions.add(newPartition);
           } else {
             // check whether mapping was changed
    +        int currentPartitionsSize = mainPC.currentPartitions.size();
             for (DefaultPartition<Operator> pi : mainPC.currentPartitions) {
    -          if (pi == newPartition && pi.isModified()) {
    +          if (pi == newPartition && (pi.isModified() ||
    --- End diff --
    
    How that is different from a case when current partition size is 2 and new 
partition size is 3 or more and it includes 2 current partitions? Is the 
behavior different because there were no unifiers? But unifiers may never come 
into the picture or be introduced several operators downstream. The problem 
seems to be in the definePartitions() that returns the current partition. I may 
be wrong, but I don't see why it is necessary to handle current partition size 
equal to one differently in the modified code.


> Window id of downstream operator is not moving after dynamic partition of 
> upstream operator.
> --------------------------------------------------------------------------------------------
>
>                 Key: APEXCORE-494
>                 URL: https://issues.apache.org/jira/browse/APEXCORE-494
>             Project: Apache Apex Core
>          Issue Type: Bug
>            Reporter: Chaitanya
>            Assignee: Chaitanya
>         Attachments: PhysicalDAGAfterKafkaRepartition.png, 
> PhysicalDAGBeforeKafkaRepartition.png, 
> PhysicalOperatorAfterKafkaRepartition.png
>
>
> Created the following application to reproduce this issue.
> Application has the following DAG:
>    KafkaSinglePortStringInputOperator(Input) -> ConsoleOutputOperator(Output)
>    
>    I launched the application with below configuration:
> Kafka topic created with single partition and replication factor as 1.
> Partition Strategy: ONE_TO_ONE
>    Launched the application successfully. After some time, I increased the 
> topic partitions to 2. After re-partition, the window of down stream operator 
> is not moving. By looking into the app Physical DAG, it looks like there is 
> an issue in construction of Physical DAG after re-partition.



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

Reply via email to