[
https://issues.apache.org/jira/browse/APEXCORE-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15367945#comment-15367945
]
ASF GitHub Bot commented on APEXCORE-222:
-----------------------------------------
Github user vrozov commented on a diff in the pull request:
https://github.com/apache/apex-core/pull/350#discussion_r70103320
--- Diff:
bufferserver/src/main/java/com/datatorrent/bufferserver/server/Server.java ---
@@ -199,6 +199,13 @@ private void handlePurgeRequest(PurgeRequestTuple
request, final AbstractLengthP
}
}
+ public void purge(long windowId)
+ {
+ for (DataList dataList: publisherBuffers.values()) {
--- End diff --
It is not thread safe to access HashMap (publisherBuffers) from 2 different
threads in a case when one thread modifies HashMap (adds or removes entries in
the HashMap). It is not fine as there is a race condition between purge() and
handlePublisherRequest().
> 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)
