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 <[email protected]> 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 <[email protected]> Authored: Wed Dec 9 17:39:53 2015 -0600 Committer: Gwen Shapira <[email protected]> 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>
