[
https://issues.apache.org/jira/browse/APEXCORE-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081605#comment-15081605
]
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_r48768048
--- Diff: api/src/main/java/com/datatorrent/api/Operator.java ---
@@ -99,6 +99,25 @@ public String toString()
}
/**
+ * DelayOperator is an operator of which the outgoing streaming window
id is incremented by *one* by the
+ * engine, thus allowing loops in the "DAG". The output ports of a
DelayOperator, if connected, *must*
+ * immediately connect to an upstream operator in the data flow path.
Note that at least one output port of
+ * DelayOperator should be connected in order for the DelayOperator to
serve its purpose.
+ *
+ * This is meant for iterative algorithms in the topology. A larger
window increment can be simulated by an
+ * implementation of this interface.
+ */
+ interface DelayOperator extends Operator
+ {
+ /**
+ * This method gets called at the first window of the execution.
+ * The implementation is expected to emit tuples for initialization
and/or
+ * recovery.
+ */
+ void firstWindow();
--- End diff --
We concluded that the window id was not needed since the implementation
could easily get that by storing the window id as part of the checkpoint state.
> 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
> Labels: roadmap
> Fix For: 3.3.0
>
>
> 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)
