kafka-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From guozh...@apache.org
Subject [kafka] branch 2.4 updated: KAFKA-8729: Add upgrade docs for KIP-467 on augmented produce response (#7522)
Date Fri, 25 Oct 2019 02:46:25 GMT
This is an automated email from the ASF dual-hosted git repository.

guozhang pushed a commit to branch 2.4
in repository https://gitbox.apache.org/repos/asf/kafka.git

The following commit(s) were added to refs/heads/2.4 by this push:
     new 3fe6b5e  KAFKA-8729: Add upgrade docs for KIP-467 on augmented produce response (#7522)
3fe6b5e is described below

commit 3fe6b5e951db8f7184a4098f8ad8a1afb2b2c1a0
Author: Guozhang Wang <wangguoz@gmail.com>
AuthorDate: Thu Oct 24 19:45:09 2019 -0700

    KAFKA-8729: Add upgrade docs for KIP-467 on augmented produce response (#7522)
    Add a paragraph explaining the producer caller's expected behavior change on record validation
failure scenarios that are improved by KIP-467.
    Reviewers: Tu V. Tran <tu@confluent.io>, Jason Gustafson <jason@confluent.io>
 docs/upgrade.html | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/docs/upgrade.html b/docs/upgrade.html
index 65c7ba9..8bc0fb9 100644
--- a/docs/upgrade.html
+++ b/docs/upgrade.html
@@ -87,6 +87,13 @@
         The old overloaded functions are deprecated and we would recommend users to make
their code changes to leverage the new methods (details
         can be found in <a href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-520%3A+Add+overloaded+Consumer%23committed+for+batching+partitions">KIP-520</a>).
+    <li>We've introduced a new <code>INVALID_RECORD</code> error in the
produce response to distinguish from the <code>CORRUPT_MESSAGE</code> error.
+        To be more concrete, previously when a batch of records were sent as part of a single
request to the broker and one or more of the records failed
+        the validation due to various causes (mismatch magic bytes, crc checksum errors,
null key for log compacted topics, etc), the whole batch would be rejected
+        with the same and misleading <code>CORRUPT_MESSAGE</code>, and the caller
of the producer client would see the corresponding exception from either
+        the future object of <code>RecordMetadata</code> returned from the <code>send</code>
call as well as in the <code>Callback#onCompletion(RecordMetadata metadata, Exception
+        Now with the new error code and improved error messages of the exception, producer
callers would be better informed about the root cause why their sent records were failed.
+    </li>
     <li>We are introducing incremental cooperative rebalancing to the clients' group
protocol, which allows consumers to keep all of their assigned partitions during a rebalance
         and at the end revoke only those which must be migrated to another consumer for overall
cluster balance. The <code>ConsumerCoordinator</code> will choose the latest <code>RebalanceProtocol</code>
         that is commonly supported by all of the consumer's supported assignors. You can
use the new built-in <code>CooperativeStickyAssignor</code> or plug in your own
custom cooperative assignor. To do

View raw message