From f7fc2853868caa3b8a044b6d5d52ce26ae2a3677 Mon Sep 17 00:00:00 2001 From: Alex Loddengaard Date: Wed, 9 Dec 2015 17:39:53 -0600 Subject: [PATCH] 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 Reviewers: Grant Henke, Gwen Shapira Closes #654 from alexlod/doc-typo-fixes --- docs/design.html | 2 +- docs/introduction.html | 2 +- docs/ops.html | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/design.html b/docs/design.html index e0284685e91..61845e3444e 100644 --- a/docs/design.html +++ b/docs/design.html @@ -359,7 +359,7 @@ Further cleaner configurations are described Why are quotas necessary?

-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.

Enforcement

diff --git a/docs/introduction.html b/docs/introduction.html index e5b2e78e589..4173ff61db7 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

If all the consumer instances have different consumer groups, then this works like publish-subscribe and all messages are broadcast to all consumers.

-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.

diff --git a/docs/ops.html b/docs/ops.html index 04d4e7ac869..49c6f4ebf48 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
  • 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. -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: 
         controlled.shutdown.enable=true