This is an automated email from the ASF dual-hosted git repository.
chia7712 pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/kafka.git
The following commit(s) were added to refs/heads/trunk by this push:
new 49bf46e8873 MINOR: clean typos and grammar across quickstart, connect,
streams, and MirrorMaker docs (#21709)
49bf46e8873 is described below
commit 49bf46e8873a4a041c46260170432ae7b67fecc5
Author: Charlie Zhang <[email protected]>
AuthorDate: Mon Mar 23 00:28:05 2026 +0000
MINOR: clean typos and grammar across quickstart, connect, streams, and
MirrorMaker docs (#21709)
## Summary
This PR fixes documentation typos and grammar issues across several docs
pages.
## Changes
- `docs/getting-started/quickstart.md`
- Fix punctuation in Step 8 sentence (`environment-or` ->
`environment, or`).
- `docs/kafka-connect/user-guide.md`
- Fix typo: `task statues` -> `task statuses`.
- `docs/operations/geo-replication-(cross-cluster-data-mirroring).md`
- Fix grammar: `can be specified the MirrorMaker config` -> `can be
specified in the MirrorMaker config`.
- Fix markdown spacing/formatting around a link (`See the[...` -> `See
the [...`), and remove trailing bold-format spacing issue.
- `docs/streams/developer-guide/config-streams.md`
- Fix grammar: `these thread` -> `these threads`.
- Fix grammar: `three brokers what is` -> `three brokers, which is`.
- `docs/streams/developer-guide/manage-topics.md`
- Remove duplicate word: `then ... then`.
## Scope
- Docs-only changes.
- No code, behavior, or configuration changes.
Reviewers: Sanskar Jhajharia <[email protected]>, Chia-Ping Tsai
<[email protected]>
---
docs/getting-started/quickstart.md | 2 +-
docs/kafka-connect/user-guide.md | 2 +-
docs/operations/geo-replication-(cross-cluster-data-mirroring).md | 4 ++--
docs/streams/developer-guide/config-streams.md | 4 ++--
docs/streams/developer-guide/manage-topics.md | 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/docs/getting-started/quickstart.md
b/docs/getting-started/quickstart.md
index 2e9858728fa..b0896074771 100644
--- a/docs/getting-started/quickstart.md
+++ b/docs/getting-started/quickstart.md
@@ -203,7 +203,7 @@ The [Kafka Streams demo](/documentation/streams/quickstart)
and the [app develop
## Step 8: Terminate the Kafka environment
-Now that you reached the end of the quickstart, feel free to tear down the
Kafka environment-or continue playing around.
+Now that you reached the end of the quickstart, feel free to tear down the
Kafka environment or continue playing around.
1. Stop the producer and consumer clients with `Ctrl-C`, if you haven't done
so already.
2. Stop the Kafka broker with `Ctrl-C`.
diff --git a/docs/kafka-connect/user-guide.md b/docs/kafka-connect/user-guide.md
index 24c5fe71579..d859a0ba6e4 100644
--- a/docs/kafka-connect/user-guide.md
+++ b/docs/kafka-connect/user-guide.md
@@ -63,7 +63,7 @@ Distributed mode handles automatic balancing of work, allows
you to scale up (or
$ bin/connect-distributed.sh config/connect-distributed.properties
-The difference is in the class which is started and the configuration
parameters which change how the Kafka Connect process decides where to store
configurations, how to assign work, and where to store offsets and task
statues. In the distributed mode, Kafka Connect stores the offsets, configs and
task statuses in Kafka topics. It is recommended to manually create the topics
for offset, configs and statuses in order to achieve the desired the number of
partitions and replication factors. [...]
+The difference is in the class which is started and the configuration
parameters which change how the Kafka Connect process decides where to store
configurations, how to assign work, and where to store offsets and task
statuses. In the distributed mode, Kafka Connect stores the offsets, configs
and task statuses in Kafka topics. It is recommended to manually create the
topics for offset, configs and statuses to achieve the desired number of
partitions and replication factors. If the topi [...]
In particular, the following configuration parameters, in addition to the
common settings mentioned above, are critical to set before starting your
cluster:
diff --git a/docs/operations/geo-replication-(cross-cluster-data-mirroring).md
b/docs/operations/geo-replication-(cross-cluster-data-mirroring).md
index 780a5a35a9a..f68f09b71d1 100644
--- a/docs/operations/geo-replication-(cross-cluster-data-mirroring).md
+++ b/docs/operations/geo-replication-(cross-cluster-data-mirroring).md
@@ -168,13 +168,13 @@ For new MirrorMaker clusters, set the
`exactly.once.source.support` property to
For existing MirrorMaker clusters, a two-step upgrade is necessary. Instead of
immediately setting the `exactly.once.source.support` property to enabled,
first set it to `preparing` on all nodes in the cluster. Once this is complete,
it can be set to `enabled` on all nodes in the cluster, in a second round of
restarts.
-In either case, it is also necessary to enable intra-cluster communication
between the MirrorMaker nodes, as described in
[KIP-710](https://cwiki.apache.org/confluence/x/4g5RCg). To do this, the
`dedicated.mode.enable.internal.rest` property must be set to `true`. In
addition, many of the REST-related [configuration properties available for
Kafka Connect](https://kafka.apache.org/documentation/#connectconfigs) can be
specified the MirrorMaker config. For example, to enable intra-cluster [...]
+In either case, it is also necessary to enable intra-cluster communication
between the MirrorMaker nodes, as described in
[KIP-710](https://cwiki.apache.org/confluence/x/4g5RCg). To do this, the
`dedicated.mode.enable.internal.rest` property must be set to `true`. In
addition, many of the REST-related [configuration properties available for
Kafka Connect](https://kafka.apache.org/documentation/#connectconfigs) can be
specified in the MirrorMaker config. For example, to enable intra-clust [...]
dedicated.mode.enable.internal.rest = true
listeners = http://localhost:8080
-**Note that, if intra-cluster communication is enabled in production
environments, it is highly recommended to secure the REST servers brought up by
each MirrorMaker node. See the[configuration properties for Kafka
Connect](https://kafka.apache.org/documentation/#connectconfigs) for
information on how this can be accomplished. **
+**Note that, if intra-cluster communication is enabled in production
environments, it is highly recommended to secure the REST servers brought up by
each MirrorMaker node. See the [configuration properties for Kafka
Connect](https://kafka.apache.org/documentation/#connectconfigs) for
information on how this can be accomplished.**
It is also recommended to filter records from aborted transactions out from
replicated data when running MirrorMaker. To do this, ensure that the consumer
used to read from source clusters is configured with `isolation.level` set to
`read_committed`. If replicating data from cluster `us-west`, this can be done
for all replication flows that read from that cluster by adding the following
to the MirrorMaker config file:
diff --git a/docs/streams/developer-guide/config-streams.md
b/docs/streams/developer-guide/config-streams.md
index 265e58f9c20..40802a67c1f 100644
--- a/docs/streams/developer-guide/config-streams.md
+++ b/docs/streams/developer-guide/config-streams.md
@@ -1453,7 +1453,7 @@ Serde for the inner class of a windowed record. Must
implement the `Serde` inter
### num.stream.threads
-> This specifies the number of stream threads in an instance of the Kafka
Streams application. The stream processing code runs in these thread. For more
information about Kafka Streams threading model, see [Threading
Model](../architecture.html#streams_architecture_threads).
+> This specifies the number of stream threads in an instance of the Kafka
Streams application. The stream processing code runs in these threads. For more
information about Kafka Streams threading model, see [Threading
Model](../architecture.html#streams_architecture_threads).
### probing.rebalance.interval.ms
@@ -1529,7 +1529,7 @@ Serde for the inner class of a windowed record. Must
implement the `Serde` inter
### processing.guarantee
-> The processing guarantee that should be used. Possible values are
`"at_least_once"` (default) and `"exactly_once_v2"` (for EOS version 2).
Deprecated config options are `"exactly_once"` (for EOS alpha), and
`"exactly_once_beta"` (for EOS version 2). Using `"exactly_once_v2"` (or the
deprecated `"exactly_once_beta"`) requires broker version 2.5 or newer, while
using the deprecated `"exactly_once"` requires broker version 0.11.0 or newer.
Note that if exactly-once processing is enabled, [...]
+> The processing guarantee that should be used. Possible values are
`"at_least_once"` (default) and `"exactly_once_v2"` (for EOS version 2).
Deprecated config options are `"exactly_once"` (for EOS alpha), and
`"exactly_once_beta"` (for EOS version 2). Using `"exactly_once_v2"` (or the
deprecated `"exactly_once_beta"`) requires broker version 2.5 or newer, while
using the deprecated `"exactly_once"` requires broker version 0.11.0 or newer.
Note that if exactly-once processing is enabled, [...]
>
> Recommendation:
> While it is technically possible to use EOS with any replication factor,
> using a replication factor lower than 3 effectively voids EOS. Thus it is
> strongly recommended to use a replication factor of 3 (together with
> `min.in.sync.replicas=2`). This recommendation applies to all topics (i.e.
> `__transaction_state`, `__consumer_offsets`, Kafka Streams internal topics,
> and user topics).
diff --git a/docs/streams/developer-guide/manage-topics.md
b/docs/streams/developer-guide/manage-topics.md
index aff7d8151cd..478359e5877 100644
--- a/docs/streams/developer-guide/manage-topics.md
+++ b/docs/streams/developer-guide/manage-topics.md
@@ -39,7 +39,7 @@ Input topics
Output topics
Topics that are specified via sink processors in the application's
topology; e.g. via `KStream#to()`, `KTable.to()` and `Topology#addSink()`.
-User topics must be created and manually managed ahead of time (e.g., via the
[topic tools](../../kafka/post-deployment.html#kafka-operations-admin)). If
user topics are shared among multiple applications for reading and writing, the
application users must coordinate topic management. If user topics are
centrally managed, then application users then would not need to manage topics
themselves but simply obtain access to them.
+User topics must be created and manually managed ahead of time (e.g., via the
[topic tools](../../kafka/post-deployment.html#kafka-operations-admin)). If
user topics are shared among multiple applications for reading and writing, the
application users must coordinate topic management. If user topics are
centrally managed, then application users would not need to manage topics
themselves but simply obtain access to them.
Note
