Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 3B118200BD4 for ; Thu, 1 Dec 2016 13:04:37 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 399F2160B0F; Thu, 1 Dec 2016 12:04:37 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 3BD9F160B0B for ; Thu, 1 Dec 2016 13:04:36 +0100 (CET) Received: (qmail 70107 invoked by uid 500); 1 Dec 2016 12:04:35 -0000 Mailing-List: contact dev-help@apex.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@apex.apache.org Delivered-To: mailing list dev@apex.apache.org Received: (qmail 70096 invoked by uid 99); 1 Dec 2016 12:04:35 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Dec 2016 12:04:35 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id D9A701A9C68 for ; Thu, 1 Dec 2016 12:04:34 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -7.019 X-Spam-Level: X-Spam-Status: No, score=-7.019 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.999] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id qW0nkuWHoViR for ; Thu, 1 Dec 2016 12:04:34 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with SMTP id B40B45F239 for ; Thu, 1 Dec 2016 12:04:33 +0000 (UTC) Received: (qmail 68301 invoked by uid 99); 1 Dec 2016 12:03:58 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Dec 2016 12:03:58 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 9FABC2C14F3 for ; Thu, 1 Dec 2016 12:03:58 +0000 (UTC) Date: Thu, 1 Dec 2016 12:03:58 +0000 (UTC) From: "Bhupesh Chawda (JIRA)" To: dev@apex.incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (APEXCORE-581) Delivery of Custom Control Tuples MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 01 Dec 2016 12:04:37 -0000 [ https://issues.apache.org/jira/browse/APEXCORE-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15711794#comment-15711794 ] Bhupesh Chawda commented on APEXCORE-581: ----------------------------------------- Do we need to store the control tuples in the buffer server. I was thinking that the buffer server flow for all the tuples (including control tuples) would be as it is. We can intercept the tuples in GenericNode and buffer them there. Once consolidated, we could put them into the sinks at the window boundaries. > Delivery of Custom Control Tuples > --------------------------------- > > Key: APEXCORE-581 > URL: https://issues.apache.org/jira/browse/APEXCORE-581 > Project: Apache Apex Core > Issue Type: Sub-task > Reporter: David Yan > > The behavior should be as follow: > - The control tuples should only be sent to downstream at streaming window boundaries > - The control tuples should be sent to all partitions downstream > - The control tuples should be sent in the same order of arrival. > - Within a streaming window, do not send the same control tuple twice, even if the same control tuple is received multiple times within that window. This is possible if the operator has two input ports. (The LinkedHashMap should be easily able to ensure both order and uniqueness.) > - The delivery of control tuples needs to stop at DelayOperator. > - When a streaming window is committed, remove the associated LinkedHashMap that belong to windows with IDs that are less than the committed window > - It's safe to assume the control tuples are rare enough and can fit in memory > This will involve an additional MessageType to represent a custom control tuple. > We probably need to have a data structure (possibly a LinkedHashMap) per streaming window that stores the control tuple in the buffer server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)