[
https://issues.apache.org/jira/browse/APEXCORE-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15349909#comment-15349909
]
ASF GitHub Bot commented on APEXCORE-222:
-----------------------------------------
Github user sandeshh commented on a diff in the pull request:
https://github.com/apache/apex-core/pull/350#discussion_r68496137
--- Diff:
engine/src/main/java/com/datatorrent/stram/engine/StreamingContainer.java ---
@@ -769,7 +769,11 @@ public void
processHeartbeatResponse(ContainerHeartbeatResponse rsp)
}
if (rsp.committedWindowId != lastCommittedWindowId) {
+
lastCommittedWindowId = rsp.committedWindowId;
+
+ bufferServer.purge(lastCommittedWindowId);
--- End diff --
Wrote a sample application and tested this change by killing the
containers. There was no issue and the recovery started from the expected
window id ( committed + 1 ). Still not sure why we have to keep the window data
of the committed window.
> Delegate Buffer Server purge to StreamingContainer
> --------------------------------------------------
>
> Key: APEXCORE-222
> URL: https://issues.apache.org/jira/browse/APEXCORE-222
> Project: Apache Apex Core
> Issue Type: Improvement
> Reporter: Thomas Weise
> Assignee: Sandesh
>
> Currently the purge requests are sent to the buffer servers from the app
> master. This interaction exists parallel to the heartbeat protocol. Instead,
> the committed window ID that is propagated through the heartbeat response can
> be used in StreamingContainer to initiate the purge with the local buffer
> server, similar to how the committed callback on the operator occurs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
