MahsaSeifikar commented on code in PR #19141:
URL: https://github.com/apache/kafka/pull/19141#discussion_r1985262195
##########
docs/upgrade.html:
##########
@@ -74,24 +74,24 @@ <h5><a id="upgrade_400_notable"
href="#upgrade_400_notable">Notable changes in 4
<li>
The Next Generation of the Consumer Rebalance Protocol (<a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-848%3A+The+Next+Generation+of+the+Consumer+Rebalance+Protocol";>KIP-848</a>)
is now Generally Available (GA) in Apache Kafka 4.0. The protocol
is automatically enabled on the server when the upgrade to 4.0 is finalized.
- Note that once the new protocol is used by consumer groups, the
cluster can only downgrade to version 3.4.1 or newer.
- Check <a
href="/{{version}}/documentation.html#consumer_rebalance_protocol">here</a> for
details.
+ Note that once the new protocol is used by consumer groups, the
cluster can only be downgraded to version 3.4.1 or newer.
+ For more information check <a
href="/{{version}}/documentation.html#consumer_rebalance_protocol">here</a>.
</li>
<li>
- Transactions Server Side Defense (<a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-890%3A+Transactions+Server-Side+Defense";>KIP-890</a>)
+ Transactions Server-Side Defense (<a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-890%3A+Transactions+Server-Side+Defense";>KIP-890</a>)
brings a strengthened transactional protocol to Apache Kafka 4.0.
The new and improved transactional protocol is enabled when the upgrade to 4.0
is finalized.
When using 4.0 producer clients, the producer epoch is bumped on
every transaction to ensure every transaction includes the intended messages
and duplicates are not
- written as part of the next transaction. Downgrading the protocol
is safe. For more information check <a
href="/{{version}}/documentation.html#transaction_protocol">here</a>
+ written as part of the next transaction. Downgrading the protocol
is safe. For more information check <a
href="/{{version}}/documentation.html#transaction_protocol">here</a>.
</li>
<li>
Eligible Leader Replicas (<a
href="https://cwiki.apache.org/confluence/display/KAFKA/KIP-966%3A+Eligible+Leader+Replicas";>KIP-966
Part 1</a>)
enhances the replication protocol for the Apache Kafka 4.0. Now
the KRaft controller keeps track of the data partition replicas that are
not included in ISR but are safe to be elected as leader without
data loss. Such replicas are stored in the partition metadata as
the <code>Eligible Leader Replicas</code>(ELR).
- For more information check <a
href="/{{version}}/documentation.html#eligible_leader_replicas">here</a>
+ For more information check <a
href="/{{version}}/documentation.html#eligible_leader_replicas">here</a>.
</li>
<li>
- Since Apache Kafka 4.0.0, we have added a system property
("org.apache.kafka.sasl.oauthbearer.allowed.urls") to
+ Since Apache Kafka 4.0.0, we have added a system property
(<code>org.apache.kafka.sasl.oauthbearer.allowed.urls</code>) to
set the allowed URLs as SASL OAUTHBEARER token or jwks endpoints.
By default, the value is an empty list.
Review Comment:
Good point! I just found in
[KIP-255](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75968876)
they used `SASL/OAUTHBEARER`
--
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.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
