[
https://issues.apache.org/jira/browse/APEXCORE-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15115662#comment-15115662
]
ASF GitHub Bot commented on APEXCORE-201:
-----------------------------------------
Github user gauravgopi123 commented on a diff in the pull request:
https://github.com/apache/incubator-apex-core/pull/194#discussion_r50730068
--- Diff:
engine/src/main/java/com/datatorrent/stram/StreamingContainerManager.java ---
@@ -1695,6 +1607,42 @@ public void run()
}
endWindowStatsMap.put(shb.getNodeId(), endWindowStats);
+ if (!oper.getInputs().isEmpty()) {
+ long latency = Long.MAX_VALUE;
--- End diff --
@davidyan74 : Consider following scenario
For window W1, stats are received in following order A,C,B and Latency (A)
< Latency(B) but since B arrived later than C, C adds A as it's slowest
upstream.
For Window W2, stats are received in B,A,C order and new Latency(A) > new
Latency(B), now again C adds A as it's slowest upstream.
B is never added as slowest upstream for C in this scenario.
Again it depends on how accurate you want to show the latency values.
> Reported latency is wrong when a downstream operator is behind more than 1000
> windows
> -------------------------------------------------------------------------------------
>
> Key: APEXCORE-201
> URL: https://issues.apache.org/jira/browse/APEXCORE-201
> Project: Apache Apex Core
> Issue Type: Bug
> Reporter: David Yan
> Assignee: David Yan
>
> We should probably estimate this by reporting the latency using the number of
> windows behind when that happens. Right now it reports a stale latency.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
