[ https://issues.apache.org/jira/browse/APEXCORE-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15349773#comment-15349773 ]
ASF GitHub Bot commented on APEXCORE-222: ----------------------------------------- Github user tweise commented on a diff in the pull request: https://github.com/apache/apex-core/pull/350#discussion_r68493464 --- 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 -- Please address the question regarding the windowId. If it isn't decremented, aren't we blowing away the checkpoint 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)