apex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (APEXCORE-222) Delegate Buffer Server purge to StreamingContainer
Date Fri, 08 Jul 2016 16:39:11 GMT

    [ 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:

    --- Diff: bufferserver/src/main/java/com/datatorrent/bufferserver/server/Server.java ---
    @@ -199,6 +199,13 @@ private void handlePurgeRequest(PurgeRequestTuple request, final
    +  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

This message was sent by Atlassian JIRA

View raw message