This is an automated email from the ASF dual-hosted git repository.
jgus pushed a commit to branch 3.3
in repository https://gitbox.apache.org/repos/asf/kafka.git
The following commit(s) were added to refs/heads/3.3 by this push:
new 07a448295f7 MINOR: Small update docs/design.html grammar and typo
(#12691)
07a448295f7 is described below
commit 07a448295f75754bc2aa7ed8c9e959c17e51e800
Author: Chase Thomas <[email protected]>
AuthorDate: Tue Sep 27 11:46:25 2022 -0700
MINOR: Small update docs/design.html grammar and typo (#12691)
Reviewers: Jason Gustafson <[email protected]>
---
docs/design.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/design.html b/docs/design.html
index b37300f23e5..9485ab9c500 100644
--- a/docs/design.html
+++ b/docs/design.html
@@ -322,7 +322,7 @@
Followers consume messages from the leader just as a normal Kafka consumer
would and apply them to their own log. Having the followers pull from the
leader has the nice property of allowing the follower to naturally
batch together log entries they are applying to their log.
<p>
- As with most distributed systems automatically handling failures requires
having a precise definition of what it means for a node to be "alive." In
Kafka, a special node
+ As with most distributed systems, automatically handling failures requires
a precise definition of what it means for a node to be "alive." In Kafka, a
special node
known as the "controller" is responsible for managing the registration of
brokers in the cluster. Broker liveness has two conditions:
<ol>
<li>Brokers must maintain an active session with the controller in order
to receive regular metadata updates.</li>
@@ -335,7 +335,7 @@
<p>
For clusters using Zookeeper, liveness is determined indirectly through
the existence of an ephemeral node which is created by the broker on
initialization of its Zookeeper session. If the broker loses its session
after failing to send heartbeats to Zookeeper before expiration of
- <code>zookeeper.session.timeout.ms</code>, the the node gets deleted. The
controller would then notice the node deletion through a Zookeeper watch
+ <code>zookeeper.session.timeout.ms</code>, then the node gets deleted. The
controller would then notice the node deletion through a Zookeeper watch
and mark the broker offline.
<p>
We refer to nodes satisfying these two conditions as being "in sync" to
avoid the vagueness of "alive" or "failed". The leader keeps track of the set
of "in sync" replicas,
