kafka-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gwens...@apache.org
Subject kafka git commit: MINOR: Trivial doc/ typo fixes.
Date Wed, 09 Dec 2015 23:39:57 GMT
Repository: kafka
Updated Branches:
  refs/heads/trunk 7bb7e415a -> f7fc28538


MINOR: Trivial doc/ typo fixes.

The change in `docs/design.html` is hard to catch in the diff -- a `tbe` is changed to `the`.
All other changes show up clearly in the diff.

This contribution is my original work and I license the work to the project under the project's
open source license.

Author: Alex Loddengaard <alexloddengaard@gmail.com>

Reviewers: Grant Henke, Gwen Shapira

Closes #654 from alexlod/doc-typo-fixes


Project: http://git-wip-us.apache.org/repos/asf/kafka/repo
Commit: http://git-wip-us.apache.org/repos/asf/kafka/commit/f7fc2853
Tree: http://git-wip-us.apache.org/repos/asf/kafka/tree/f7fc2853
Diff: http://git-wip-us.apache.org/repos/asf/kafka/diff/f7fc2853

Branch: refs/heads/trunk
Commit: f7fc2853868caa3b8a044b6d5d52ce26ae2a3677
Parents: 7bb7e41
Author: Alex Loddengaard <alexloddengaard@gmail.com>
Authored: Wed Dec 9 17:39:53 2015 -0600
Committer: Gwen Shapira <cshapi@gmail.com>
Committed: Wed Dec 9 17:39:53 2015 -0600

----------------------------------------------------------------------
 docs/design.html       | 2 +-
 docs/introduction.html | 2 +-
 docs/ops.html          | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/kafka/blob/f7fc2853/docs/design.html
----------------------------------------------------------------------
diff --git a/docs/design.html b/docs/design.html
index e028468..61845e3 100644
--- a/docs/design.html
+++ b/docs/design.html
@@ -359,7 +359,7 @@ Further cleaner configurations are described <a href="/documentation.html#broker
 
 <h4><a id="design_quotasnecessary" href="#design_quotasnecessary">Why are quotas
necessary?</a></h4>
 <p>
-It is possible for producers and consumers to produce/consume very high volumes of data and
thus monopolize broker resources, cause network saturation and generally DOS other clients
and the brokers themselves. Having quotas protects against these issues and is all tbe more
important in large multi-tenant clusters where a small set of badly behaved clients can degrade
user experience for the well behaved ones. In fact, when running Kafka as a service this even
makes it possible to enforce API limits according to an agreed upon contract.
+It is possible for producers and consumers to produce/consume very high volumes of data and
thus monopolize broker resources, cause network saturation and generally DOS other clients
and the brokers themselves. Having quotas protects against these issues and is all the more
important in large multi-tenant clusters where a small set of badly behaved clients can degrade
user experience for the well behaved ones. In fact, when running Kafka as a service this even
makes it possible to enforce API limits according to an agreed upon contract.
 </p>
 <h4><a id="design_quotasenforcement" href="#design_quotasenforcement">Enforcement</a></h4>
 <p>

http://git-wip-us.apache.org/repos/asf/kafka/blob/f7fc2853/docs/introduction.html
----------------------------------------------------------------------
diff --git a/docs/introduction.html b/docs/introduction.html
index e5b2e78..4173ff6 100644
--- a/docs/introduction.html
+++ b/docs/introduction.html
@@ -72,7 +72,7 @@ If all the consumer instances have the same consumer group, then this works
just
 <p>
 If all the consumer instances have different consumer groups, then this works like publish-subscribe
and all messages are broadcast to all consumers.
 <p>
-More commonly, however, we have found that topics have a small number of consumer groups,
one for each "logical subscriber". Each group is composed of many consumer instances for scalability
and fault tolerance. This is nothing more than publish-subscribe semantics where the subscriber
is cluster of consumers instead of a single process.
+More commonly, however, we have found that topics have a small number of consumer groups,
one for each "logical subscriber". Each group is composed of many consumer instances for scalability
and fault tolerance. This is nothing more than publish-subscribe semantics where the subscriber
is a cluster of consumers instead of a single process.
 <p>
 
 <div style="float: right; margin: 20px; width: 500px" class="caption">

http://git-wip-us.apache.org/repos/asf/kafka/blob/f7fc2853/docs/ops.html
----------------------------------------------------------------------
diff --git a/docs/ops.html b/docs/ops.html
index 04d4e7a..49c6f4e 100644
--- a/docs/ops.html
+++ b/docs/ops.html
@@ -74,7 +74,7 @@ When a server is stopped gracefully it has two optimizations it will take
advant
     <li>It will migrate any partitions the server is the leader for to other replicas
prior to shutting down. This will make the leadership transfer faster and minimize the time
each partition is unavailable to a few milliseconds.
 </ol>
 
-Syncing the logs will happen automatically happen whenever the server is stopped other than
by a hard kill, but the controlled leadership migration requires using a special setting:
+Syncing the logs will happen automatically whenever the server is stopped other than by a
hard kill, but the controlled leadership migration requires using a special setting:
 <pre>
     controlled.shutdown.enable=true
 </pre>


Mime
View raw message