kafka-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From guozh...@apache.org
Subject kafka git commit: MINOR: update KStream JavaDocs
Date Thu, 15 Dec 2016 23:54:33 GMT
Repository: kafka
Updated Branches:
  refs/heads/trunk e36e8079d -> c2cfadf25


MINOR: update KStream JavaDocs

Author: Matthias J. Sax <matthias@confluent.io>

Reviewers: Guozhang Wang <wangguoz@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 <matthias@confluent.io>
Authored: Thu Dec 15 15:54:29 2016 -0800
Committer: Guozhang Wang <wangguoz@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>&lt;K3:ValueJoiner(null,c)&gt;</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&mdash;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>&lt;K3:ValueJoiner(null,c)&gt;</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&mdash;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>&lt;K1:ValueJoiner(C,b)&gt;</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>&lt;K1:ValueJoiner(C,b)&gt;</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>&lt;K1:ValueJoiner(C,b)&gt;</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>&lt;K1:ValueJoiner(C,b)&gt;</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.


Mime
View raw message