[
https://issues.apache.org/jira/browse/APEXCORE-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15387910#comment-15387910
]
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_r71728748
--- 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 --
@tweise Thomas, are partitions in `mainPC.currentPartitions` unique? It
looks like, there are. Should in this case currentPartitions be declared as
HashSet instead of ArrayList to explicitly enforce uniqueness? It should be
also possible to avoid iterating over currentPartitions
```
if (op == null) {
addedPartitions.add(newPartition);
} else if (((DefaultPartition)newPartition).isModified()) {
// check whether mapping was changed
for (DefaultPartition<Operator> currentPartition :
mainPC.currentPartitions) {
if (currentPartition == newPartition) {
// existing partition changed (operator or partition keys)
// remove/add to update subscribers and state
mainPC.currentPartitionMap.put(newPartition, op);
addedPartitions.add(newPartition);
break;
}
}
}
```
> 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)
