[ 
https://issues.apache.org/jira/browse/APEXCORE-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15065624#comment-15065624
 ] 

ASF GitHub Bot commented on APEXCORE-60:
----------------------------------------

Github user davidyan74 commented on a diff in the pull request:

    https://github.com/apache/incubator-apex-core/pull/185#discussion_r48099738
  
    --- Diff: 
common/src/main/java/com/datatorrent/common/util/DefaultDelayOperator.java ---
    @@ -0,0 +1,57 @@
    +/**
    + * Licensed to the Apache Software Foundation (ASF) under one
    + * or more contributor license agreements.  See the NOTICE file
    + * distributed with this work for additional information
    + * regarding copyright ownership.  The ASF licenses this file
    + * to you under the Apache License, Version 2.0 (the
    + * "License"); you may not use this file except in compliance
    + * with the License.  You may obtain a copy of the License at
    + *
    + *   http://www.apache.org/licenses/LICENSE-2.0
    + *
    + * Unless required by applicable law or agreed to in writing,
    + * software distributed under the License is distributed on an
    + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
    + * KIND, either express or implied.  See the License for the
    + * specific language governing permissions and limitations
    + * under the License.
    + */
    +package com.datatorrent.common.util;
    +
    +import java.util.ArrayList;
    +import java.util.List;
    +
    +/**
    + * DefaultDelayOperator. This is the version of BaseDelayOperator that 
provides no data loss during recovery. It
    + * incurs a run-time cost per tuple, and all tuples of the checkpoint 
window will be part of the checkpoint state.
    + * Therefore if your application can tolerate data loss at recovery, 
BaseDelayOperator should be used instead.
    + */
    +public class DefaultDelayOperator<T> extends BaseDelayOperator<T>
    --- End diff --
    
    WindowDataManager should have much better performance than this since it 
spreads the writing of the tuples throughout the entire window.


> Iterative processing support
> ----------------------------
>
>                 Key: APEXCORE-60
>                 URL: https://issues.apache.org/jira/browse/APEXCORE-60
>             Project: Apache Apex Core
>          Issue Type: New Feature
>            Reporter: David Yan
>            Assignee: David Yan
>
> We would like to support iterative processing by introducing cycles in the 
> graph (known as DAG now, but no longer if we support iterative processing).
> Initial idea is as follow:
> {noformat}
>      |----|
>      v    |
> A -> B -> C -> D
> ^         |
> |---------|
> {noformat} 
> C has two separate backward streams to A and B.  The input ports of A and B 
> that C connects to will have a special attribute on how many window IDs ahead 
> the incoming windows should be treated as, and A and B will be responsible 
> for the initial data for such input ports.
> Another idea is to have C advance the window ID on its output ports and have 
> C generate the initial data on its output ports to A and B.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to