zhijiangW commented on a change in pull request #9717: [FLINK-14044] [runtime]
Reducing synchronization in AsyncWaitOperator
URL: https://github.com/apache/flink/pull/9717#discussion_r328422187
##########
File path:
flink-streaming-java/src/main/java/org/apache/flink/streaming/api/operators/async/queue/UnorderedStreamElementQueue.java
##########
@@ -19,192 +19,146 @@
package org.apache.flink.streaming.api.operators.async.queue;
import org.apache.flink.annotation.Internal;
-import org.apache.flink.streaming.api.operators.async.OperatorActions;
+import org.apache.flink.streaming.api.functions.async.ResultFuture;
+import org.apache.flink.streaming.api.operators.TimestampedCollector;
+import org.apache.flink.streaming.api.watermark.Watermark;
+import org.apache.flink.streaming.runtime.streamrecord.StreamElement;
+import org.apache.flink.streaming.runtime.streamrecord.StreamRecord;
import org.apache.flink.util.Preconditions;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.util.ArrayDeque;
-import java.util.Arrays;
+import java.util.ArrayList;
import java.util.Collection;
+import java.util.Deque;
import java.util.HashSet;
-import java.util.Iterator;
+import java.util.List;
+import java.util.Optional;
+import java.util.Queue;
import java.util.Set;
-import java.util.concurrent.Executor;
-import java.util.concurrent.locks.Condition;
-import java.util.concurrent.locks.ReentrantLock;
/**
- * Unordered implementation of the {@link StreamElementQueue}. The unordered
stream element queue
- * emits asynchronous results as soon as they are completed. Additionally it
maintains the
- * watermark-stream record order. This means that no stream record can be
overtaken by a watermark
- * and no watermark can overtake a stream record. However, stream records
falling in the same
- * segment between two watermarks can overtake each other (their emission
order is not guaranteed).
+ * Unordered implementation of the {@link StreamElementQueue}. The unordered
stream element queue provides
+ * asynchronous results as soon as they are completed. Additionally it
maintains the watermark-stream record order.
Review comment:
Yes. Elements within a stage could overtake each other. One more thing for
further confirmation: how to guarantee that two stages can not overtake each
other?
e.g. assuming we have four stages : {a, b, c} {watermark1} {d, e, f}
{watermark2}, and the first stage is the {a, b, c}. If the user function
completes the element `e` in third stage firstly, that means the collection of
`e` would be emitted to output before the first stage? Or I missed something
else.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
