[
https://issues.apache.org/jira/browse/APEXCORE-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15254587#comment-15254587
]
ASF GitHub Bot commented on APEXCORE-439:
-----------------------------------------
Github user tweise commented on a diff in the pull request:
https://github.com/apache/incubator-apex-core/pull/314#discussion_r60797952
--- Diff:
engine/src/main/java/com/datatorrent/stram/StreamingContainerManager.java ---
@@ -2272,7 +2329,7 @@ public void deploy(Set<PTContainer>
releaseContainers, Collection<PTOperator> un
for (PTOperator oper : e.getValue()) {
// operator will be deployed after it has been undeployed, if
still referenced by the container
if (oper.getState() != PTOperator.State.PENDING_UNDEPLOY) {
- oper.setState(PTOperator.State.PENDING_DEPLOY);
+ oper.setState(PTOperator.State.PENDING_UNDEPLOY);
--- End diff --
Can you please check what happens in the initial for loop that sets all
operators to UNDEPLOY? Why isn't the operator marked there?
> 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)
