You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@kafka.apache.org by gu...@apache.org on 2016/12/15 23:54:33 UTC
kafka git commit: MINOR: update KStream JavaDocs
Repository: kafka
Updated Branches:
refs/heads/trunk e36e8079d -> c2cfadf25
MINOR: update KStream JavaDocs
Author: Matthias J. Sax <ma...@confluent.io>
Reviewers: Guozhang Wang <wa...@gmail.com>
Closes #2258 from mjsax/minorKStreamJavaDoc
Project: http://git-wip-us.apache.org/repos/asf/kafka/repo
Commit: http://git-wip-us.apache.org/repos/asf/kafka/commit/c2cfadf2
Tree: http://git-wip-us.apache.org/repos/asf/kafka/tree/c2cfadf2
Diff: http://git-wip-us.apache.org/repos/asf/kafka/diff/c2cfadf2
Branch: refs/heads/trunk
Commit: c2cfadf254c9d5da14db1db9a4a3889c20192f60
Parents: e36e807
Author: Matthias J. Sax <ma...@confluent.io>
Authored: Thu Dec 15 15:54:29 2016 -0800
Committer: Guozhang Wang <wa...@gmail.com>
Committed: Thu Dec 15 15:54:29 2016 -0800
----------------------------------------------------------------------
.../apache/kafka/streams/kstream/KStream.java | 66 --------------------
1 file changed, 66 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/kafka/blob/c2cfadf2/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java
----------------------------------------------------------------------
diff --git a/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java b/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java
index eb46311..f5ad24c 100644
--- a/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java
+++ b/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java
@@ -919,9 +919,6 @@ public interface KStream<K, V> {
* <td></td>
* </tr>
* </table>
- * Keep in mind, that the <em>order</em> of the result depends on the non-deterministic processing order of the
- * input streams.
- * <p>
* Both input streams need to be co-partitioned on the join key.
* If this requirement is not met, Kafka Streams will automatically repartition the data, i.e., it will create an
* internal repartitioning topic in Kafka and write and re-read the data via this topic before the actual join.
@@ -993,9 +990,6 @@ public interface KStream<K, V> {
* <td></td>
* </tr>
* </table>
- * Keep in mind, that the <em>order</em> of the result depends on the non-deterministic processing order of the
- * input streams.
- * <p>
* Both input streams need to be co-partitioned on the join key.
* If this requirement is not met, Kafka Streams will automatically repartition the data, i.e., it will create an
* internal repartitioning topic in Kafka and write and re-read the data via this topic before the actual join.
@@ -1081,15 +1075,6 @@ public interface KStream<K, V> {
* <td></td>
* </tr>
* </table>
- * Keep in mind, that the <em>order</em> of the result depends on the non-deterministic processing order of the
- * input streams.
- * The non-deterministic processing order might also lead to unexpected (but correct) results due to eager join
- * evaluation strategy:
- * Assume that for {@code K2} record {@code <K2:B>} gets processed first.
- * As {@code <K2:b>} is not known at this point in time, there will be a result {@code <K2:ValueJoiner(B,null)>}
- * first; later, when {@code <K2:b>} gets processed the expected result {@code <K2:ValueJoiner(B,b)>} will be
- * computed, too.
- * <p>
* Both input streams need to be co-partitioned on the join key.
* If this requirement is not met, Kafka Streams will automatically repartition the data, i.e., it will create an
* internal repartitioning topic in Kafka and write and re-read the data via this topic before the actual join.
@@ -1166,15 +1151,6 @@ public interface KStream<K, V> {
* <td></td>
* </tr>
* </table>
- * Keep in mind, that the <em>order</em> of the result depends on the non-deterministic processing order of the
- * input streams.
- * The non-deterministic processing order might also lead to unexpected (but correct) results due to eager join
- * evaluation strategy:
- * Assume that for {@code K2} record {@code <K2:B>} gets processed first.
- * As {@code <K2:b>} is not known at this point in time, there will be a result {@code <K2:ValueJoiner(B,null)>}
- * first; later, when {@code <K2:b>} gets processed the expected result {@code <K2:ValueJoiner(B,b)>} will be
- * computed, too.
- * <p>
* Both input streams need to be co-partitioned on the join key.
* If this requirement is not met, Kafka Streams will automatically repartition the data, i.e., it will create an
* internal repartitioning topic in Kafka and write and re-read the data via this topic before the actual join.
@@ -1262,17 +1238,6 @@ public interface KStream<K, V> {
* <td><K3:ValueJoiner(null,c)></td>
* </tr>
* </table>
- * Keep in mind, that the <em>order</em> of the result depends on the non-deterministic processing order of the
- * input streams.
- * Due to eager join evaluation strategy you will get some additional results (that might be unexpected):
- * Assume that for {@code K2} record {@code <K2:B>} gets processed first.
- * As {@code <K2:b>} is not known at this point in time, there will be a result {@code <K2:ValueJoiner(B,null)>}
- * first; later, when {@code <K2:b>} gets processed the expected result {@code <K2:ValueJoiner(B,b)>} will be
- * computed, too.
- * Thus, for each matching result pair, there will be one additional non-matching result (either non-matching from
- * this-to-other, or non-matching from other-to-this—which one of both will be in the result depends on
- * non-deterministic processing order).
- * <p>
* Both input streams need to be co-partitioned on the join key.
* If this requirement is not met, Kafka Streams will automatically repartition the data, i.e., it will create an
* internal repartitioning topic in Kafka and write and re-read the data via this topic before the actual join.
@@ -1350,17 +1315,6 @@ public interface KStream<K, V> {
* <td><K3:ValueJoiner(null,c)></td>
* </tr>
* </table>
- * Keep in mind, that the <em>order</em> of the result depends on the non-deterministic processing order of the
- * input streams.
- * Due to eager join evaluation strategy you will get some additional results (that might be unexpected):
- * Assume that for {@code K2} record {@code <K2:B>} gets processed first.
- * As {@code <K2:b>} is not known at this point in time, there will be a result {@code <K2:ValueJoiner(B,null)>}
- * first; later, when {@code <K2:b>} gets processed the expected result {@code <K2:ValueJoiner(B,b)>} will be
- * computed, too.
- * Thus, for each matching result pair, there will be one additional non-matching result (either non-matching from
- * this-to-other, or non-matching from other-to-this—which one of both will be in the result depends on
- * non-deterministic processing order).
- * <p>
* Both input streams need to be co-partitioned on the join key.
* If this requirement is not met, Kafka Streams will automatically repartition the data, i.e., it will create an
* internal repartitioning topic in Kafka and write and re-read the data via this topic before the actual join.
@@ -1450,11 +1404,6 @@ public interface KStream<K, V> {
* <td><K1:ValueJoiner(C,b)></td>
* </tr>
* </table>
- * Keep in mind, that the result depends on the non-deterministic processing order of the input streams because
- * the lookup is done on the <em>current</em> (i.e., processing time) state of {@link KTable}. Kafka Streams tries
- * to synchronize the stream with the table state on event time, but there is no guarantee about the computed result.
- * Event time synchronization of both {@link KStream} and {@link KTable} happens with a best-effort approach.
- * <p>
* Both input streams need to be co-partitioned on the join key.
* If this requirement is not met, Kafka Streams will automatically repartition the data, i.e., it will create an
* internal repartitioning topic in Kafka and write and re-read the data via this topic before the actual join.
@@ -1522,11 +1471,6 @@ public interface KStream<K, V> {
* <td><K1:ValueJoiner(C,b)></td>
* </tr>
* </table>
- * Keep in mind, that the result depends on the non-deterministic processing order of the input streams because
- * the lookup is done on the <em>current</em> (i.e., processing time) state of {@link KTable}. Kafka Streams tries
- * to synchronize the stream with the table state on event time, but there is no guarantee about the computed result.
- * Event time synchronization of both {@link KStream} and {@link KTable} happens with a best-effort approach.
- * <p>
* Both input streams need to be co-partitioned on the join key.
* If this requirement is not met, Kafka Streams will automatically repartition the data, i.e., it will create an
* internal repartitioning topic in Kafka and write and re-read the data via this topic before the actual join.
@@ -1604,11 +1548,6 @@ public interface KStream<K, V> {
* <td><K1:ValueJoiner(C,b)></td>
* </tr>
* </table>
- * Keep in mind, that the result depends on the non-deterministic processing order of the input streams because
- * the lookup is done on the <em>current</em> (i.e., processing time) state of {@link KTable}. Kafka Streams tries
- * to synchronize the stream with the table state on event time, but there is no guarantee about the computed result.
- * Event time synchronization of both {@link KStream} and {@link KTable} happens with a best-effort approach.
- * <p>
* Both input streams need to be co-partitioned on the join key.
* If this requirement is not met, Kafka Streams will automatically repartition the data, i.e., it will create an
* internal repartitioning topic in Kafka and write and re-read the data via this topic before the actual join.
@@ -1679,11 +1618,6 @@ public interface KStream<K, V> {
* <td><K1:ValueJoiner(C,b)></td>
* </tr>
* </table>
- * Keep in mind, that the result depends on the non-deterministic processing order of the input streams because
- * the lookup is done on the <em>current</em> (i.e., processing time) state of {@link KTable}. Kafka Streams tries
- * to synchronize the stream with the table state on event time, but there is no guarantee about the computed result.
- * Event time synchronization of both {@link KStream} and {@link KTable} happens with a best-effort approach.
- * <p>
* Both input streams need to be co-partitioned on the join key.
* If this requirement is not met, Kafka Streams will automatically repartition the data, i.e., it will create an
* internal repartitioning topic in Kafka and write and re-read the data via this topic before the actual join.