[
https://issues.apache.org/jira/browse/APEXCORE-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15330733#comment-15330733
]
ASF GitHub Bot commented on APEXCORE-222:
-----------------------------------------
Github user PramodSSImmaneni commented on a diff in the pull request:
https://github.com/apache/apex-core/pull/350#discussion_r67067166
--- 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 --
Today there is flexibility for the server to not be in the same process
even though it is not being exercised. With this change that flexibility will
be gone. How about providing both options.
> 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)
