From e4f4e50b7ba5a3b3837c33157c96c839dc57457f Mon Sep 17 00:00:00 2001 From: Mickael Maison Date: Thu, 2 Jun 2022 12:05:30 +0200 Subject: [PATCH] MINOR: Small fixes in docs/upgrade.html (#12239) Reviewers: David Jacot --- docs/upgrade.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/upgrade.html b/docs/upgrade.html index 0d7f98e3e04..33971a79c10 100644 --- a/docs/upgrade.html +++ b/docs/upgrade.html @@ -75,7 +75,7 @@
  • Kafka has replaced log4j with reload4j due to security concerns. This only affects modules that specify a logging backend (connect-runtime and kafka-tools are two such examples). A number of modules, including kafka-clients, leave it to the application to specify the logging backend. - More information can be found at reload4j. + More information can be found at reload4j. Projects that depend on the affected modules from the Kafka project should use slf4j-log4j12 version 1.7.35 or above or slf4j-reload4j to avoid @@ -229,7 +229,7 @@ KIP-735 for more details.
  • The broker configuration log.message.format.version and topic configuration message.format.version have been deprecated. The value of both configurations is always assumed to be 3.0 if inter.broker.protocol.version is 3.0 or higher. - If log.message.format.version or <message.format.version are set, we recommend clearing them at the same time as the + If log.message.format.version or message.format.version are set, we recommend clearing them at the same time as the inter.broker.protocol.version upgrade to 3.0. This will avoid potential compatibility issues if the inter.broker.protocol.version is downgraded. See KIP-724 for more details.
  • The Streams API removed all deprecated APIs that were deprecated in version 2.5.0 or earlier. @@ -744,7 +744,7 @@ can be found in KIP-520).
  • We've introduced a new INVALID_RECORD error in the produce response to distinguish from the CORRUPT_MESSAGE 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 + To be more concrete, previously when a batch of records was 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 CORRUPT_MESSAGE, and the caller of the producer client would see the corresponding exception from either the future object of RecordMetadata returned from the send call as well as in the Callback#onCompletion(RecordMetadata metadata, Exception exception) @@ -1893,7 +1893,7 @@ work with 0.10.0.x brokers. Therefore, 0.9.0.0 clients should be upgraded to 0.9 To maintain compatibility with old clients, this change only applies to Message format 0.10.0 and later. Clients that Produce/Fetch LZ4-compressed messages using v0/v1 (Message format 0.9.0) should continue to use the 0.9.0 framing implementation. Clients that use Produce/Fetch protocols v2 or later - should use interoperable LZ4f framing. A list of interoperable LZ4 libraries is available at http://www.lz4.org/ + should use interoperable LZ4f framing. A list of interoperable LZ4 libraries is available at https://www.lz4.org/
    Notable changes in 0.10.0.0