You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@kafka.apache.org by ju...@apache.org on 2015/11/18 03:44:56 UTC
[1/3] kafka-site git commit: upload latest 0.9.0 docs
Repository: kafka-site
Updated Branches:
refs/heads/asf-site fdd6433bd -> 24d8d665e
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/serialization/ByteArrayDeserializer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/serialization/ByteArrayDeserializer.html b/090/javadoc/org/apache/kafka/common/serialization/ByteArrayDeserializer.html
index 8f98f03..faa5ea3 100644
--- a/090/javadoc/org/apache/kafka/common/serialization/ByteArrayDeserializer.html
+++ b/090/javadoc/org/apache/kafka/common/serialization/ByteArrayDeserializer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>ByteArrayDeserializer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/serialization/ByteArraySerializer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/serialization/ByteArraySerializer.html b/090/javadoc/org/apache/kafka/common/serialization/ByteArraySerializer.html
index bef894a..71681fa 100644
--- a/090/javadoc/org/apache/kafka/common/serialization/ByteArraySerializer.html
+++ b/090/javadoc/org/apache/kafka/common/serialization/ByteArraySerializer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>ByteArraySerializer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/serialization/Deserializer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/serialization/Deserializer.html b/090/javadoc/org/apache/kafka/common/serialization/Deserializer.html
index c9f086b..e3358ac 100644
--- a/090/javadoc/org/apache/kafka/common/serialization/Deserializer.html
+++ b/090/javadoc/org/apache/kafka/common/serialization/Deserializer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>Deserializer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/serialization/IntegerDeserializer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/serialization/IntegerDeserializer.html b/090/javadoc/org/apache/kafka/common/serialization/IntegerDeserializer.html
index 7e285b7..d6768cb 100644
--- a/090/javadoc/org/apache/kafka/common/serialization/IntegerDeserializer.html
+++ b/090/javadoc/org/apache/kafka/common/serialization/IntegerDeserializer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>IntegerDeserializer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/serialization/IntegerSerializer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/serialization/IntegerSerializer.html b/090/javadoc/org/apache/kafka/common/serialization/IntegerSerializer.html
index 0ba5cb0..e1dd089 100644
--- a/090/javadoc/org/apache/kafka/common/serialization/IntegerSerializer.html
+++ b/090/javadoc/org/apache/kafka/common/serialization/IntegerSerializer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>IntegerSerializer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/serialization/LongDeserializer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/serialization/LongDeserializer.html b/090/javadoc/org/apache/kafka/common/serialization/LongDeserializer.html
index 5499dd7..0b58719 100644
--- a/090/javadoc/org/apache/kafka/common/serialization/LongDeserializer.html
+++ b/090/javadoc/org/apache/kafka/common/serialization/LongDeserializer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>LongDeserializer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/serialization/LongSerializer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/serialization/LongSerializer.html b/090/javadoc/org/apache/kafka/common/serialization/LongSerializer.html
index 1d99e97..49d52e0 100644
--- a/090/javadoc/org/apache/kafka/common/serialization/LongSerializer.html
+++ b/090/javadoc/org/apache/kafka/common/serialization/LongSerializer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>LongSerializer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/serialization/Serializer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/serialization/Serializer.html b/090/javadoc/org/apache/kafka/common/serialization/Serializer.html
index 0e88312..69ca220 100644
--- a/090/javadoc/org/apache/kafka/common/serialization/Serializer.html
+++ b/090/javadoc/org/apache/kafka/common/serialization/Serializer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>Serializer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/serialization/StringDeserializer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/serialization/StringDeserializer.html b/090/javadoc/org/apache/kafka/common/serialization/StringDeserializer.html
index 0f8947a..fed4830 100644
--- a/090/javadoc/org/apache/kafka/common/serialization/StringDeserializer.html
+++ b/090/javadoc/org/apache/kafka/common/serialization/StringDeserializer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>StringDeserializer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/serialization/StringSerializer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/serialization/StringSerializer.html b/090/javadoc/org/apache/kafka/common/serialization/StringSerializer.html
index afe335f..eaa4a04 100644
--- a/090/javadoc/org/apache/kafka/common/serialization/StringSerializer.html
+++ b/090/javadoc/org/apache/kafka/common/serialization/StringSerializer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>StringSerializer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/serialization/package-frame.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/serialization/package-frame.html b/090/javadoc/org/apache/kafka/common/serialization/package-frame.html
index f5b0c55..5e66acc 100644
--- a/090/javadoc/org/apache/kafka/common/serialization/package-frame.html
+++ b/090/javadoc/org/apache/kafka/common/serialization/package-frame.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.common.serialization (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/serialization/package-summary.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/serialization/package-summary.html b/090/javadoc/org/apache/kafka/common/serialization/package-summary.html
index e4f7d26..364ac89 100644
--- a/090/javadoc/org/apache/kafka/common/serialization/package-summary.html
+++ b/090/javadoc/org/apache/kafka/common/serialization/package-summary.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.common.serialization (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/serialization/package-tree.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/serialization/package-tree.html b/090/javadoc/org/apache/kafka/common/serialization/package-tree.html
index 044da2d..5c005b6 100644
--- a/090/javadoc/org/apache/kafka/common/serialization/package-tree.html
+++ b/090/javadoc/org/apache/kafka/common/serialization/package-tree.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.common.serialization Class Hierarchy (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/overview-frame.html
----------------------------------------------------------------------
diff --git a/090/javadoc/overview-frame.html b/090/javadoc/overview-frame.html
index 8106f11..989bbbe 100644
--- a/090/javadoc/overview-frame.html
+++ b/090/javadoc/overview-frame.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>Overview List (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/overview-summary.html
----------------------------------------------------------------------
diff --git a/090/javadoc/overview-summary.html b/090/javadoc/overview-summary.html
index 12d1e03..5fcda96 100644
--- a/090/javadoc/overview-summary.html
+++ b/090/javadoc/overview-summary.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>Overview (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/overview-tree.html
----------------------------------------------------------------------
diff --git a/090/javadoc/overview-tree.html b/090/javadoc/overview-tree.html
index d6f3519..714c997 100644
--- a/090/javadoc/overview-tree.html
+++ b/090/javadoc/overview-tree.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>Class Hierarchy (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/serialized-form.html
----------------------------------------------------------------------
diff --git a/090/javadoc/serialized-form.html b/090/javadoc/serialized-form.html
index 29fd75a..1d4f8d3 100644
--- a/090/javadoc/serialized-form.html
+++ b/090/javadoc/serialized-form.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>Serialized Form (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/kafka_config.html
----------------------------------------------------------------------
diff --git a/090/kafka_config.html b/090/kafka_config.html
index c56b29e..4cac226 100644
--- a/090/kafka_config.html
+++ b/090/kafka_config.html
@@ -200,7 +200,7 @@
<tr>
<td>num.partitions</td><td>The default number of log partitions per topic</td><td>int</td><td>1</td><td>[1,...]</td><td>medium</td></tr>
<tr>
-<td>principal.builder.class</td><td>principal builder to generate a java Principal. This config is optional for client.</td><td>class</td><td>class org.apache.kafka.common.security.auth.DefaultPrincipalBuilder</td><td></td><td>medium</td></tr>
+<td>principal.builder.class</td><td>The fully qualified name of a class that implements the PrincipalBuilder interface, which is currently used to build the Principal for connections with the SSL SecurityProtocol. Default is DefaultPrincipalBuilder.</td><td>class</td><td>class org.apache.kafka.common.security.auth.DefaultPrincipalBuilder</td><td></td><td>medium</td></tr>
<tr>
<td>producer.purgatory.purge.interval.requests</td><td>The purge interval (in number of requests) of the producer request purgatory</td><td>int</td><td>1000</td><td></td><td>medium</td></tr>
<tr>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/migration.html
----------------------------------------------------------------------
diff --git a/090/migration.html b/090/migration.html
index 18ab6d4..2da6a7e 100644
--- a/090/migration.html
+++ b/090/migration.html
@@ -5,9 +5,9 @@
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
-
+
http://www.apache.org/licenses/LICENSE-2.0
-
+
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -16,11 +16,11 @@
-->
<!--#include virtual="../includes/header.html" -->
-<h2>Migrating from 0.7.x to 0.8</h2>
+<h2><a id="migration" href="#migration">Migrating from 0.7.x to 0.8</a></h2>
0.8 is our first (and hopefully last) release with a non-backwards-compatible wire protocol, ZooKeeper layout, and on-disk data format. This was a chance for us to clean up a lot of cruft and start fresh. This means performing a no-downtime upgrade is more painful than normal—you cannot just swap in the new code in-place.
-<h3>Migration Steps</h3>
+<h3><a id="migration_steps" href="#migration_steps">Migration Steps</a></h3>
<ol>
<li>Setup a new cluster running 0.8.
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/ops.html
----------------------------------------------------------------------
diff --git a/090/ops.html b/090/ops.html
index af1c15c..2624527 100644
--- a/090/ops.html
+++ b/090/ops.html
@@ -5,9 +5,9 @@
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
-
+
http://www.apache.org/licenses/LICENSE-2.0
-
+
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -17,17 +17,17 @@
Here is some information on actually running Kafka as a production system based on usage and experience at LinkedIn. Please send us any additional tips you know of.
-<h3><a id="basic_ops">6.1 Basic Kafka Operations</a></h3>
+<h3><a id="basic_ops" href="#basic_ops">6.1 Basic Kafka Operations</a></h3>
This section will review the most common operations you will perform on your Kafka cluster. All of the tools reviewed in this section are available under the <code>bin/</code> directory of the Kafka distribution and each tool will print details on all possible commandline options if it is run with no arguments.
-
-<h4><a id="basic_ops_add_topic">Adding and removing topics</a></h4>
+
+<h4><a id="basic_ops_add_topic" href="#basic_ops_add_topic">Adding and removing topics</a></h4>
You have the option of either adding topics manually or having them be created automatically when data is first published to a non-existent topic. If topics are auto-created then you may want to tune the default <a href="#topic-config">topic configurations</a> used for auto-created topics.
<p>
Topics are added and modified using the topic tool:
<pre>
- > bin/kafka-topics.sh --zookeeper zk_host:port/chroot --create --topic my_topic_name
+ > bin/kafka-topics.sh --zookeeper zk_host:port/chroot --create --topic my_topic_name
--partitions 20 --replication-factor 3 --config x=y
</pre>
The replication factor controls how many servers will replicate each message that is written. If you have a replication factor of 3 then up to 2 servers can fail before you will lose access to your data. We recommend you use a replication factor of 2 or 3 so that you can transparently bounce machines without interrupting data consumption.
@@ -36,14 +36,14 @@ The partition count controls how many logs the topic will be sharded into. There
<p>
The configurations added on the command line override the default settings the server has for things like the length of time data should be retained. The complete set of per-topic configurations is documented <a href="#topic-config">here</a>.
-<h4><a id="basic_ops_modify_topic">Modifying topics</a></h4>
+<h4><a id="basic_ops_modify_topic" href="#basic_ops_modify_topic">Modifying topics</a></h4>
You can change the configuration or partitioning of a topic using the same topic tool.
<p>
To add partitions you can do
<pre>
- > bin/kafka-topics.sh --zookeeper zk_host:port/chroot --alter --topic my_topic_name
- --partitions 40
+ > bin/kafka-topics.sh --zookeeper zk_host:port/chroot --alter --topic my_topic_name
+ --partitions 40
</pre>
Be aware that one use case for partitions is to semantically partition data, and adding partitions doesn't change the partitioning of existing data so this may disturb consumers if they rely on that partition. That is if data is partitioned by <code>hash(key) % number_of_partitions</code> then this partitioning will potentially be shuffled by adding partitions but Kafka will not attempt to automatically redistribute data in any way.
<p>
@@ -64,7 +64,7 @@ Topic deletion option is disabled by default. To enable it set the server config
<p>
Kafka does not currently support reducing the number of partitions for a topic or changing the replication factor.
-<h4><a id="basic_ops_restarting">Graceful shutdown</a></h4>
+<h4><a id="basic_ops_restarting" href="#basic_ops_restarting">Graceful shutdown</a></h4>
The Kafka cluster will automatically detect any broker shutdown or failure and elect new leaders for the partitions on that machine. This will occur whether a server fails or it is brought down intentionally for maintenance or configuration changes. For the later cases Kafka supports a more graceful mechanism for stoping a server then just killing it.
@@ -80,7 +80,7 @@ Syncing the logs will happen automatically happen whenever the server is stopped
</pre>
Note that controlled shutdown will only succeed if <i>all</i> the partitions hosted on the broker have replicas (i.e. the replication factor is greater than 1 <i>and</i> at least one of these replicas is alive). This is generally what you want since shutting down the last replica would make that topic partition unavailable.
-<h4><a id="basic_ops_leader_balancing">Balancing leadership</a></h4>
+<h4><a id="basic_ops_leader_balancing" href="#basic_ops_leader_balancing">Balancing leadership</a></h4>
Whenever a broker stops or crashes leadership for that broker's partitions transfers to other replicas. This means that by default when the broker is restarted it will only be a follower for all its partitions, meaning it will not be used for client reads and writes.
<p>
@@ -94,7 +94,7 @@ Since running this command can be tedious you can also configure Kafka to do thi
auto.leader.rebalance.enable=true
</pre>
-<h4><a id="basic_ops_mirror_maker">Mirroring data between clusters</a></h4>
+<h4><a id="basic_ops_mirror_maker" href="#basic_ops_mirror_maker">Mirroring data between clusters</a></h4>
We refer to the process of replicating data <i>between</i> Kafka clusters "mirroring" to avoid confusion with the replication that happens amongst the nodes in a single cluster. Kafka comes with a tool for mirroring data between Kafka clusters. The tool reads from a source cluster and writes to a destination cluster, like this:
<p>
@@ -111,7 +111,7 @@ The source and destination clusters are completely independent entities: they ca
Here is an example showing how to mirror a single topic (named <i>my-topic</i>) from two input clusters:
<pre>
> bin/kafka-run-class.sh kafka.tools.MirrorMaker
- --consumer.config consumer-1.properties --consumer.config consumer-2.properties
+ --consumer.config consumer-1.properties --consumer.config consumer-2.properties
--producer.config producer.properties --whitelist my-topic
</pre>
Note that we specify the list of topics with the <code>--whitelist</code> option. This option allows any regular expression using <a href="http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html">Java-style regular expressions</a>. So you could mirror two topics named <i>A</i> and <i>B</i> using <code>--whitelist 'A|B'</code>. Or you could mirror <i>all</i> topics using <code>--whitelist '*'</code>. Make sure to quote any regular expression to ensure the shell doesn't try to expand it as a file path. For convenience we allow the use of ',' instead of '|' to specify a list of topics.
@@ -120,7 +120,7 @@ Sometime it is easier to say what it is that you <i>don't</i> want. Instead of u
<p>
Combining mirroring with the configuration <code>auto.create.topics.enable=true</code> makes it possible to have a replica cluster that will automatically create and replicate all data in a source cluster even as new topics are added.
-<h4><a id="basic_ops_consumer_lag">Checking consumer position</a></h4>
+<h4><a id="basic_ops_consumer_lag" href="#basic_ops_consumer_lag">Checking consumer position</a></h4>
Sometimes it's useful to see the position of your consumers. We have a tool that will show the position of all consumers in a consumer group as well as how far behind the end of the log they are. To run this tool on a consumer group named <i>my-group</i> consuming a topic named <i>my-topic</i> would look like this:
<pre>
> bin/kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --zkconnect localhost:2181 --group test
@@ -129,13 +129,13 @@ my-group my-topic 0 0 0
my-group my-topic 1 0 0 0 test_jkreps-mn-1394154521217-1a0be913-0
</pre>
-<h4><a id="basic_ops_cluster_expansion">Expanding your cluster</a></h4>
+<h4><a id="basic_ops_cluster_expansion" href="#basic_ops_cluster_expansion">Expanding your cluster</a></h4>
Adding servers to a Kafka cluster is easy, just assign them a unique broker id and start up Kafka on your new servers. However these new servers will not automatically be assigned any data partitions, so unless partitions are moved to them they won't be doing any work until new topics are created. So usually when you add machines to your cluster you will want to migrate some existing data to these machines.
<p>
The process of migrating data is manually initiated but fully automated. Under the covers what happens is that Kafka will add the new server as a follower of the partition it is migrating and allow it to fully replicate the existing data in that partition. When the new server has fully replicated the contents of this partition and joined the in-sync replica one of the existing replicas will delete their partition's data.
<p>
-The partition reassignment tool can be used to move partitions across brokers. An ideal partition distribution would ensure even data load and partition sizes across all brokers.
+The partition reassignment tool can be used to move partitions across brokers. An ideal partition distribution would ensure even data load and partition sizes across all brokers. The partition reassignment tool does not have the capability to automatically study the data distribution in a Kafka cluster and move partitions around to attain an even load distribution. As such, the admin has to figure out which topics or partitions should be moved around.
<p>
The partition reassignment tool can run in 3 mutually exclusive modes -
<ul>
@@ -143,8 +143,8 @@ The partition reassignment tool can run in 3 mutually exclusive modes -
<li>--execute: In this mode, the tool kicks off the reassignment of partitions based on the user provided reassignment plan. (using the --reassignment-json-file option). This can either be a custom reassignment plan hand crafted by the admin or provided by using the --generate option</li>
<li>--verify: In this mode, the tool verifies the status of the reassignment for all partitions listed during the last --execute. The status can be either of successfully completed, failed or in progress</li>
</ul>
-<h5>Automatically migrating data to new machines</h5>
-The partition reassignment tool can be used to move some topics off of the current set of brokers to the newly added brokers. This is typically useful while expanding an existing cluster since it is easier to move entire topics to the new set of brokers, than moving one partition at a time. When used to do this, the user should provide a list of topics that should be moved to the new set of brokers and a target list of new brokers. The tool then evenly distributes all partitions for the given list of topics across the new set of brokers. During this move, the replication factor of the topic is kept constant. Effectively the replicas for all partitions for the input list of topics are moved from the old set of brokers to the newly added brokers.
+<h5><a id="basic_ops_automigrate" href="#basic_ops_automigrate">Automatically migrating data to new machines</a></h5>
+The partition reassignment tool can be used to move some topics off of the current set of brokers to the newly added brokers. This is typically useful while expanding an existing cluster since it is easier to move entire topics to the new set of brokers, than moving one partition at a time. When used to do this, the user should provide a list of topics that should be moved to the new set of brokers and a target list of new brokers. The tool then evenly distributes all partitions for the given list of topics across the new set of brokers. During this move, the replication factor of the topic is kept constant. Effectively the replicas for all partitions for the input list of topics are moved from the old set of brokers to the newly added brokers.
<p>
For instance, the following example will move all partitions for topics foo1,foo2 to the new set of brokers 5,6. At the end of this move, all partitions for topics foo1 and foo2 will <i>only</i> exist on brokers 5,6
<p>
@@ -158,7 +158,7 @@ Since, the tool accepts the input list of topics as a json file, you first need
</pre>
Once the json file is ready, use the partition reassignment tool to generate a candidate assignment-
<pre>
-> bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --topics-to-move-json-file topics-to-move.json --broker-list "5,6" --generate
+> bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --topics-to-move-json-file topics-to-move.json --broker-list "5,6" --generate
Current partition replica assignment
{"version":1,
@@ -216,11 +216,11 @@ Reassignment of partition [foo1,0] completed successfully
Reassignment of partition [foo1,1] is in progress
Reassignment of partition [foo1,2] is in progress
Reassignment of partition [foo2,0] completed successfully
-Reassignment of partition [foo2,1] completed successfully
-Reassignment of partition [foo2,2] completed successfully
+Reassignment of partition [foo2,1] completed successfully
+Reassignment of partition [foo2,2] completed successfully
</pre>
-<h5>Custom partition assignment and migration</h5>
+<h5><a id="basic_ops_partitionassignment" href="#basic_ops_partitionassignment">Custom partition assignment and migration</a></h5>
The partition reassignment tool can also be used to selectively move replicas of a partition to a specific set of brokers. When used in this manner, it is assumed that the user knows the reassignment plan and does not require the tool to generate a candidate reassignment, effectively skipping the --generate step and moving straight to the --execute step
<p>
For instance, the following example moves partition 0 of topic foo1 to brokers 5,6 and partition 1 of topic foo2 to brokers 2,3
@@ -253,14 +253,14 @@ The --verify option can be used with the tool to check the status of the partiti
bin/kafka-reassign-partitions.sh --zookeeper localhost:2181 --reassignment-json-file custom-reassignment.json --verify
Status of partition reassignment:
Reassignment of partition [foo1,0] completed successfully
-Reassignment of partition [foo2,1] completed successfully
+Reassignment of partition [foo2,1] completed successfully
</pre>
-<h4><a id="basic_ops_decommissioning_brokers">Decommissioning brokers</a></h4>
+<h4><a id="basic_ops_decommissioning_brokers" href="#basic_ops_decommissioning_brokers">Decommissioning brokers</a></h4>
The partition reassignment tool does not have the ability to automatically generate a reassignment plan for decommissioning brokers yet. As such, the admin has to come up with a reassignment plan to move the replica for all partitions hosted on the broker to be decommissioned, to the rest of the brokers. This can be relatively tedious as the reassignment needs to ensure that all the replicas are not moved from the decommissioned broker to only one other broker. To make this process effortless, we plan to add tooling support for decommissioning brokers in the future.
-<h4><a id="basic_ops_increase_replication_factor">Increasing replication factor</a></h4>
-Increasing the replication factor of an existing partition is easy. Just specify the extra replicas in the custom reassignment json file and use it with the --execute option to increase the replication factor of the specified partitions.
+<h4><a id="basic_ops_increase_replication_factor" href="#basic_ops_increase_replication_factor">Increasing replication factor</a></h4>
+Increasing the replication factor of an existing partition is easy. Just specify the extra replicas in the custom reassignment json file and use it with the --execute option to increase the replication factor of the specified partitions.
<p>
For instance, the following example increases the replication factor of partition 0 of topic foo from 1 to 3. Before increasing the replication factor, the partition's only replica existed on broker 5. As part of increasing the replication factor, we will add more replicas on brokers 6 and 7.
<p>
@@ -297,7 +297,7 @@ Topic:foo PartitionCount:1 ReplicationFactor:3 Configs:
Topic: foo Partition: 0 Leader: 5 Replicas: 5,6,7 Isr: 5,6,7
</pre>
-<h4><a id="quotas">Setting quotas</a></h4>
+<h4><a id="quotas" href="#quotas">Setting quotas</a></h4>
It is possible to set default quotas that apply to all client-ids by setting these configs on the brokers. By default, each client-id receives an unlimited quota. The following sets the default quota per producer and consumer client-id to 10MB/sec.
<pre>
quota.producer.default=10485760
@@ -316,7 +316,7 @@ Here's how to describe the quota for a given client.
Configs for clients:clientA are producer_byte_rate=1024,consumer_byte_rate=2048
</pre>
-<h3><a id="datacenters">6.2 Datacenters</a></h3>
+<h3><a id="datacenters" href="#datacenters">6.2 Datacenters</a></h3>
Some deployments will need to manage a data pipeline that spans multiple datacenters. Our recommended approach to this is to deploy a local Kafka cluster in each datacenter with application instances in each datacenter interacting only with their local cluster and mirroring between clusters (see the documentation on the <a href="#basic_ops_mirror_maker">mirror maker tool</a> for how to do this).
<p>
@@ -326,13 +326,13 @@ For applications that need a global view of all data you can use mirroring to pr
<p>
This is not the only possible deployment pattern. It is possible to read from or write to a remote Kafka cluster over the WAN, though obviously this will add whatever latency is required to get the cluster.
<p>
-Kafka naturally batches data in both the producer and consumer so it can achieve high-throughput even over a high-latency connection. To allow this though it may be necessary to increase the TCP socket buffer sizes for the producer, consumer, and broker using the <code>socket.send.buffer.bytes</code> and <code>socket.receive.buffer.bytes</code> configurations. The appropriate way to set this is documented <a href="http://en.wikipedia.org/wiki/Bandwidth-delay_product">here</a>.
+Kafka naturally batches data in both the producer and consumer so it can achieve high-throughput even over a high-latency connection. To allow this though it may be necessary to increase the TCP socket buffer sizes for the producer, consumer, and broker using the <code>socket.send.buffer.bytes</code> and <code>socket.receive.buffer.bytes</code> configurations. The appropriate way to set this is documented <a href="http://en.wikipedia.org/wiki/Bandwidth-delay_product">here</a>.
<p>
It is generally <i>not</i> advisable to run a <i>single</i> Kafka cluster that spans multiple datacenters over a high-latency link. This will incur very high replication latency both for Kafka writes and ZooKeeper writes, and neither Kafka nor ZooKeeper will remain available in all locations if the network between locations is unavailable.
-<h3><a id="config">6.3 Kafka Configuration</a></h3>
+<h3><a id="config" href="#config">6.3 Kafka Configuration</a></h3>
-<h4><a id="clientconfig">Important Client Configurations</a></h4>
+<h4><a id="clientconfig" href="#clientconfig">Important Client Configurations</a></h4>
The most important producer configurations control
<ul>
<li>compression</li>
@@ -343,7 +343,7 @@ The most important consumer configuration is the fetch size.
<p>
All configurations are documented in the <a href="#configuration">configuration</a> section.
<p>
-<h4><a id="prodconfig">A Production Server Config</a></h4>
+<h4><a id="prodconfig" href="#prodconfig">A Production Server Config</a></h4>
Here is our server production server configuration:
<pre>
# Replication configurations
@@ -389,7 +389,7 @@ producer.purgatory.purge.interval.requests=100
Our client configuration varies a fair amount between different use cases.
-<h3><a id="java">Java Version</a></h3>
+<h3><a id="java" href="#java">Java Version</a></h3>
We're currently running JDK 1.7 u51, and we've switched over to the G1 collector. If you do this (and we highly recommend it), make sure you're on u51. We tried out u21 in testing, but we had a number of problems with the GC implementation in that version.
Our tuning looks like this:
@@ -405,20 +405,20 @@ For reference, here are the stats on one of LinkedIn's busiest clusters (at peak
- 70 MB/sec inbound, 400 MB/sec+ outbound
The tuning looks fairly aggressive, but all of the brokers in that cluster have a 90% GC pause time of about 21ms, and they're doing less than 1 young GC per second.
-
-<h3><a id="hwandos">6.4 Hardware and OS</a></h3>
+
+<h3><a id="hwandos" href="#hwandos">6.4 Hardware and OS</a></h3>
We are using dual quad-core Intel Xeon machines with 24GB of memory.
<p>
You need sufficient memory to buffer active readers and writers. You can do a back-of-the-envelope estimate of memory needs by assuming you want to be able to buffer for 30 seconds and compute your memory need as write_throughput*30.
<p>
The disk throughput is important. We have 8x7200 rpm SATA drives. In general disk throughput is the performance bottleneck, and more disks is more better. Depending on how you configure flush behavior you may or may not benefit from more expensive disks (if you force flush often then higher RPM SAS drives may be better).
-<h4><a id="os">OS</a></h4>
+<h4><a id="os" href="#os">OS</a></h4>
Kafka should run well on any unix system and has been tested on Linux and Solaris.
<p>
We have seen a few issues running on Windows and Windows is not currently a well supported platform though we would be happy to change that.
<p>
-You likely don't need to do much OS-level tuning though there are a few things that will help performance.
+You likely don't need to do much OS-level tuning though there are a few things that will help performance.
<p>
Two configurations that may be important:
<ul>
@@ -426,7 +426,7 @@ Two configurations that may be important:
<li>We upped the max socket buffer size to enable high-performance data transfer between data centers <a href="http://www.psc.edu/index.php/networking/641-tcp-tune">described here</a>.
</ul>
-<h4><a id="diskandfs">Disks and Filesystem</a></h4>
+<h4><a id="diskandfs" href="#diskandfs">Disks and Filesystem</a></h4>
We recommend using multiple drives to get good throughput and not sharing the same drives used for Kafka data with application logs or other OS filesystem activity to ensure good latency. You can either RAID these drives together into a single volume or format and mount each drive as its own directory. Since Kafka has replication the redundancy provided by RAID can also be provided at the application level. This choice has several tradeoffs.
<p>
If you configure multiple data directories partitions will be assigned round-robin to data directories. Each partition will be entirely in one of the data directories. If data is not well balanced among partitions this can lead to load imbalance between disks.
@@ -435,7 +435,7 @@ RAID can potentially do better at balancing load between disks (although it does
<p>
Another potential benefit of RAID is the ability to tolerate disk failures. However our experience has been that rebuilding the RAID array is so I/O intensive that it effectively disables the server, so this does not provide much real availability improvement.
-<h4><a id="appvsosflush">Application vs. OS Flush Management</a></h4>
+<h4><a id="appvsosflush" href="#appvsosflush">Application vs. OS Flush Management</a></h4>
Kafka always immediately writes all data to the filesystem and supports the ability to configure the flush policy that controls when data is forced out of the OS cache and onto disk using the and flush. This flush policy can be controlled to force data to disk after a period of time or after a certain number of messages has been written. There are several choices in this configuration.
<p>
Kafka must eventually call fsync to know that data was flushed. When recovering from a crash for any log segment not known to be fsync'd Kafka will check the integrity of each message by checking its CRC and also rebuild the accompanying offset index file as part of the recovery process executed on startup.
@@ -448,7 +448,7 @@ The drawback of using application level flush settings are that this is less eff
<p>
In general you don't need to do any low-level tuning of the filesystem, but in the next few sections we will go over some of this in case it is useful.
-<h4><a id="linuxflush">Understanding Linux OS Flush Behavior</a></h4>
+<h4><a id="linuxflush" href="#linuxflush">Understanding Linux OS Flush Behavior</a></h4>
In Linux, data written to the filesystem is maintained in <a href="http://en.wikipedia.org/wiki/Page_cache">pagecache</a> until it must be written out to disk (due to an application-level fsync or the OS's own flush policy). The flushing of data is done by a set of background threads called pdflush (or in post 2.6.32 kernels "flusher threads").
<p>
@@ -467,7 +467,7 @@ Using pagecache has several advantages over an in-process cache for storing data
<li>It automatically uses all the free memory on the machine
</ul>
-<h4><a id="ext4">Ext4 Notes</a></h4>
+<h4><a id="ext4" href="#ext4">Ext4 Notes</a></h4>
Ext4 may or may not be the best filesystem for Kafka. Filesystems like XFS supposedly handle locking during fsync better. We have only tried Ext4, though.
<p>
It is not necessary to tune these settings, however those wanting to optimize performance have a few knobs that will help:
@@ -478,8 +478,8 @@ It is not necessary to tune these settings, however those wanting to optimize pe
<li>nobh: This setting controls additional ordering guarantees when using data=writeback mode. This should be safe with Kafka as we do not depend on write ordering and improves throughput and latency.
<li>delalloc: Delayed allocation means that the filesystem avoid allocating any blocks until the physical write occurs. This allows ext4 to allocate a large extent instead of smaller pages and helps ensure the data is written sequentially. This feature is great for throughput. It does seem to involve some locking in the filesystem which adds a bit of latency variance.
</ul>
-
-<h3><a id="monitoring">6.6 Monitoring</a></h3>
+
+<h3><a id="monitoring" href="#monitoring">6.6 Monitoring</a></h3>
Kafka uses Yammer Metrics for metrics reporting in both the server and the client. This can be configured to report stats using pluggable stats reporters to hook up to your monitoring system.
<p>
@@ -628,7 +628,7 @@ We pay particular we do graphing and alerting on the following metrics:
</tr>
</tbody></table>
-<h4><a id="new_producer_monitoring">New producer monitoring</a></h4>
+<h4><a id="new_producer_monitoring" href="#new_producer_monitoring">New producer monitoring</a></h4>
The following metrics are available on new producer instances.
@@ -889,15 +889,15 @@ We recommend monitor GC time and other stats and various server stats such as CP
On the client side, we recommend monitor the message/byte rate (global and per topic), request rate/size/time, and on the consumer side, max lag in messages among all partitions and min fetch request rate. For a consumer to keep up, max lag needs to be less than a threshold and min fetch rate needs to be larger than 0.
-<h4>Audit</h4>
+<h4><a id="basic_ops_audit" href="#basic_ops_audit">Audit</a></h4>
The final alerting we do is on the correctness of the data delivery. We audit that every message that is sent is consumed by all consumers and measure the lag for this to occur. For important topics we alert if a certain completeness is not achieved in a certain time period. The details of this are discussed in KAFKA-260.
-<h3><a id="zk">6.7 ZooKeeper</a></h3>
+<h3><a id="zk" href="#zk">6.7 ZooKeeper</a></h3>
-<h4><a id="zkversion">Stable version</a></h4>
+<h4><a id="zkversion" href="#zkversion">Stable version</a></h4>
At LinkedIn, we are running ZooKeeper 3.3.*. Version 3.3.3 has known serious issues regarding ephemeral node deletion and session expirations. After running into those issues in production, we upgraded to 3.3.4 and have been running that smoothly for over a year now.
-<h4><a id="zkops">Operationalizing ZooKeeper</a></h4>
+<h4><a id="zkops" href="#zkops">Operationalizing ZooKeeper</a></h4>
Operationally, we do the following for a healthy ZooKeeper installation:
<ul>
<li>Redundancy in the physical/hardware/network layout: try not to put them all in the same rack, decent (but don't go nuts) hardware, try to keep redundant power and network paths, etc.</li>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/producer_config.html
----------------------------------------------------------------------
diff --git a/090/producer_config.html b/090/producer_config.html
index 2b1809d..7ddd2cc 100644
--- a/090/producer_config.html
+++ b/090/producer_config.html
@@ -82,8 +82,6 @@
<tr>
<td>metrics.sample.window.ms</td><td>The number of samples maintained to compute metrics.</td><td>long</td><td>30000</td><td>[0,...]</td><td>low</td></tr>
<tr>
-<td>principal.builder.class</td><td>principal builder to generate a java Principal. This config is optional for client.</td><td>class</td><td>class org.apache.kafka.common.security.auth.DefaultPrincipalBuilder</td><td></td><td>low</td></tr>
-<tr>
<td>reconnect.backoff.ms</td><td>The amount of time to wait before attempting to reconnect to a given host. This avoids repeatedly connecting to a host in a tight loop. This backoff applies to all requests sent by the consumer to the broker.</td><td>long</td><td>50</td><td>[0,...]</td><td>low</td></tr>
<tr>
<td>retry.backoff.ms</td><td>The amount of time to wait before attempting to retry a failed fetch request to a given topic partition. This avoids repeated fetching-and-failing in a tight loop.</td><td>long</td><td>100</td><td>[0,...]</td><td>low</td></tr>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/quickstart.html
----------------------------------------------------------------------
diff --git a/090/quickstart.html b/090/quickstart.html
index 268ed34..14f7518 100644
--- a/090/quickstart.html
+++ b/090/quickstart.html
@@ -5,9 +5,9 @@
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
-
+
http://www.apache.org/licenses/LICENSE-2.0
-
+
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -15,11 +15,11 @@
limitations under the License.
-->
-<h3><a id="quickstart">1.3 Quick Start</a></h3>
+<h3><a id="quickstart" href="#quickstart">1.3 Quick Start</a></h3>
This tutorial assumes you are starting fresh and have no existing Kafka or ZooKeeper data.
-<h4> Step 1: Download the code </h4>
+<h4><a id="quickstart_download" href="#quickstart_download">Step 1: Download the code</a></h4>
<a href="https://www.apache.org/dyn/closer.cgi?path=/kafka/0.9.0.0/kafka_2.11-0.9.0.0.tgz" title="Kafka downloads">Download</a> the 0.9.0.0 release and un-tar it.
@@ -28,7 +28,7 @@ This tutorial assumes you are starting fresh and have no existing Kafka or ZooKe
> <b>cd kafka_2.11-0.9.0.0</b>
</pre>
-<h4>Step 2: Start the server</h4>
+<h4><a id="quickstart_startserver" href="#quickstart_startserver">Step 2: Start the server</a></h4>
<p>
Kafka uses ZooKeeper so you need to first start a ZooKeeper server if you don't already have one. You can use the convenience script packaged with kafka to get a quick-and-dirty single-node ZooKeeper instance.
@@ -47,7 +47,7 @@ Now start the Kafka server:
...
</pre>
-<h4>Step 3: Create a topic</h4>
+<h4><a id="quickstart_createtopic" href="#quickstart_createtopic">Step 3: Create a topic</a></h4>
Let's create a topic named "test" with a single partition and only one replica:
<pre>
@@ -61,19 +61,19 @@ test
</pre>
Alternatively, instead of manually creating topics you can also configure your brokers to auto-create topics when a non-existent topic is published to.
-<h4>Step 4: Send some messages</h4>
+<h4><a id="quickstart_send" href="#quickstart_send">Step 4: Send some messages</a></h4>
Kafka comes with a command line client that will take input from a file or from standard input and send it out as messages to the Kafka cluster. By default each line will be sent as a separate message.
<p>
Run the producer and then type a few messages into the console to send to the server.
<pre>
-> <b>bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test</b>
+> <b>bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test</b>
<b>This is a message</b>
<b>This is another message</b>
</pre>
-<h4>Step 5: Start a consumer</h4>
+<h4><a id="quickstart_consume" href="#quickstart_consume">Step 5: Start a consumer</a></h4>
Kafka also has a command line consumer that will dump out messages to standard output.
@@ -86,27 +86,27 @@ This is another message
If you have each of the above commands running in a different terminal then you should now be able to type messages into the producer terminal and see them appear in the consumer terminal.
</p>
<p>
-All of the command line tools have additional options; running the command with no arguments will display usage information documenting them in more detail.
+All of the command line tools have additional options; running the command with no arguments will display usage information documenting them in more detail.
</p>
-<h4>Step 6: Setting up a multi-broker cluster</h4>
+<h4><a id="quickstart_multibroker" href="#quickstart_multibroker">Step 6: Setting up a multi-broker cluster</a></h4>
So far we have been running against a single broker, but that's no fun. For Kafka, a single broker is just a cluster of size one, so nothing much changes other than starting a few more broker instances. But just to get feel for it, let's expand our cluster to three nodes (still all on our local machine).
<p>
First we make a config file for each of the brokers:
<pre>
-> <b>cp config/server.properties config/server-1.properties</b>
+> <b>cp config/server.properties config/server-1.properties</b>
> <b>cp config/server.properties config/server-2.properties</b>
</pre>
Now edit these new files and set the following properties:
<pre>
-
+
config/server-1.properties:
broker.id=1
port=9093
log.dir=/tmp/kafka-logs-1
-
+
config/server-2.properties:
broker.id=2
port=9094
@@ -138,7 +138,7 @@ Here is an explanation of output. The first line gives a summary of all the part
<li>"leader" is the node responsible for all reads and writes for the given partition. Each node will be the leader for a randomly selected portion of the partitions.
<li>"replicas" is the list of nodes that replicate the log for this partition regardless of whether they are the leader or even if they are currently alive.
<li>"isr" is the set of "in-sync" replicas. This is the subset of the replicas list that is currently alive and caught-up to the leader.
-</ul>
+</ul>
Note that in my example node 1 is the leader for the only partition of the topic.
<p>
We can run the same command on the original topic we created to see where it is:
@@ -155,7 +155,7 @@ Let's publish a few messages to our new topic:
...
<b>my test message 1</b>
<b>my test message 2</b>
-<b>^C</b>
+<b>^C</b>
</pre>
Now let's consume these messages:
<pre>
@@ -189,7 +189,7 @@ my test message 2
</pre>
-<h4>Step 7: Use Kafka Connect to import/export data</h4>
+<h4><a id="quickstart_kafkaconnect" href="#quickstart_kafkaconnect">Step 7: Use Kafka Connect to import/export data</a></h4>
Writing data from the console and writing it back to the console is a convenient place to start, but you'll probably want
to use data from other sources or export data from Kafka to other systems. For many systems, instead of writing custom
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/security.html
----------------------------------------------------------------------
diff --git a/090/security.html b/090/security.html
index 57fe874..da9c3c6 100644
--- a/090/security.html
+++ b/090/security.html
@@ -1,4 +1,4 @@
-<!--
+
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
@@ -15,7 +15,7 @@
limitations under the License.
-->
-<h3><a id="security_overview">7.1 Security Overview</a></h3>
+<h3><a id="security_overview" href="#security_overview">7.1 Security Overview</a></h3>
In release 0.9.0.0, the Kafka community added a number of features that, used either separately or together, increases security in a Kafka cluster. The following security measures are currently supported:
<ol>
<li>Authenticating clients (Producers and consumers) connections to brokers, using either SSL or SASL (Kerberos)</li>
@@ -28,11 +28,11 @@ In release 0.9.0.0, the Kafka community added a number of features that, used ei
The guides below explain how to configure and use the security features in both clients and brokers.
-<h3><a id="security_ssl">7.2 Encryption and Authentication using SSL</a></h3>
+<h3><a id="security_ssl" href="#security_ssl">7.2 Encryption and Authentication using SSL</a></h3>
Apache Kafka allows clients to connect over SSL. By default SSL is disabled but can be turned on as needed.
<ol>
- <li><h4>Generate SSL key and certificate for each Kafka broker</h4>
+ <li><h4><a id="security_ssl_key" href="#security_ssl_key">Generate SSL key and certificate for each Kafka broker</a></h4>
The first step of deploying HTTPS is to generate the key and the certificate for each machine in the cluster. You can use Java’s keytool utility to accomplish this task.
We will generate the key into a temporary keystore initially so that we can export and sign it later with CA.
<pre>$ keytool -keystore server.keystore.jks -alias localhost -validity {validity} -genkey</pre>
@@ -44,7 +44,7 @@ Apache Kafka allows clients to connect over SSL. By default SSL is disabled but
</ol>
Ensure that common name (CN) matches exactly with the fully qualified domain name (FQDN) of the server. The client compares the CN with the DNS domain name to ensure that it is indeed connecting to the desired server, not the malicious one.</li>
- <li><h4>Creating your own CA</h4>
+ <li><h4><a id="security_ssl_ca" href="#security_ssl_ca">Creating your own CA</a></h4>
After the first step, each machine in the cluster has a public-private key pair, and a certificate to identify the machine. The certificate, however, is unsigned, which means that an attacker can create such a certificate to pretend to be any machine.<p>
Therefore, it is important to prevent forged certificates by signing them for each machine in the cluster. A certificate authority (CA) is responsible for signing certificates. CA works likes a government that issues passports—the government stamps (signs) each passport so that the passport becomes difficult to forge. Other governments verify the stamps to ensure the passport is authentic. Similarly, the CA signs the certificates, and the cryptography guarantees that a signed certificate is computationally difficult to forge. Thus, as long as the CA is a genuine and trusted authority, the clients have high assurance that they are connecting to the authentic machines.
<pre>openssl req <b>-new</b> -x509 -keyout ca-key -out ca-cert -days 365</pre>
@@ -59,7 +59,7 @@ Apache Kafka allows clients to connect over SSL. By default SSL is disabled but
In contrast to the keystore in step 1 that stores each machine’s own identity, the truststore of a client stores all the certificates that the client should trust. Importing a certificate into one’s truststore also means that trusting all certificates that are signed by that certificate. As the analogy above, trusting the government (CA) also means that trusting all passports (certificates) that it has issued. This attribute is called the chains of trust, and it is particularly useful when deploying SSL on a large Kafka cluster. You can sign all certificates in the cluster with a single CA, and have all machines share the same truststore that trusts the CA. That way all machines can authenticate all other machines.</li>
- <li><h4>Signing the certificate</h4>
+ <li><h4><a id="security_ssl_signing" href="#security_ssl_signing">Signing the certificate</a></h4>
The next step is to sign all certificates generated by step 1 with the CA generated in step 2. First, you need to export the certificate from the keystore:
<pre>keytool -keystore server.keystore.jks -alias localhost -certreq -file cert-file</pre>
@@ -97,7 +97,7 @@ Apache Kafka allows clients to connect over SSL. By default SSL is disabled but
keytool -keystore server.keystore.jks -alias CARoot -import -file ca-cert
keytool -keystore server.keystore.jks -alias localhost -import -file cert-signed
</pre></li>
- <li><h4><a name="config_broker">Configuring Kafka Broker</a></h4>
+ <li><h4><a id="security_configbroker" href="#security_configbroker">Configuring Kafka Broker</a></h4>
Kafka Broker comes with the feature of listening on multiple ports thanks to [KAFKA-1809](https://issues.apache.org/jira/browse/KAFKA-1809).
We need to configure the following property in server.properties, which must have one or more comma-separated values:
<pre>listeners</pre>
@@ -143,7 +143,7 @@ Apache Kafka allows clients to connect over SSL. By default SSL is disabled but
</pre>
If the certificate does not show up or if there are any other error messages than your keystore is not setup properly.</li>
- <li><h4>Configuring Kafka Clients</h4>h4>
+ <li><h4><a id="security_configclients" href="#security_configclients">Configuring Kafka Clients</a></h4>h4>
SSL is supported only for new Kafka Producer & Consumer, the older API is not supported. The configs for SSL will be same for both producer & consumer.<br>
If client authentication is not required in the broker, then the following is a minimal configuration example:
<pre>
@@ -175,10 +175,10 @@ Apache Kafka allows clients to connect over SSL. By default SSL is disabled but
</pre>
</li>
</ol>
-<h3><a id="security_sasl">7.3 Authentication using SASL</a></h3>
+<h3><a id="security_sasl" href="#security_sasl">7.3 Authentication using SASL</a></h3>
<ol>
- <li><h4>Prerequisites</h4><br>
+ <li><h4><a id="security_sasl_prereq" href="#security_sasl_prereq">Prerequisites</a></h4><br>
<ol>
<li><b>Kerberos</b><br>
If your organization is already using a Kerberos server (for example, by using Active Directory), there is no need to install a new server just for Kafka. Otherwise you will need to install one, your Linux vendor likely has packages for Kerberos and a short guide on how to install and configure it (<a href="https://help.ubuntu.com/community/Kerberos">Ubuntu</a>, <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/installing-kerberos.html">Redhat</a>). Note that if you are using Oracle Java, you will need to download JCE policy files for your Java version and copy them to $JAVA_HOME/jre/lib/security.</li>
@@ -223,7 +223,7 @@ Apache Kafka allows clients to connect over SSL. By default SSL is disabled but
<li>In KafkaServer and KafkaClient sections we've "serviceName" this should match principal name with which kafka broker is running. In the above example principal="kafka/kafka1.hostname.com@DOMAIN.com" so we've "kafka" which is matching the principalName.</li>
</ol>
</li>
- <li><b><a name="jaas_client">Creating Client Side JAAS Config</a></b><br>
+ <li><h4><a id="security_sasl_jaas" href="#security_sasl_jaas">Creating Client Side JAAS Config</a></h4>
Clients (producers, consumers, connect workers, etc) will authenticate to the cluster with their own principal (usually with the same name as the user used for running the client), so obtain or create these principals as needed. Then create a JAAS file as follows:
<pre>
KafkaClient {
@@ -237,7 +237,7 @@ Apache Kafka allows clients to connect over SSL. By default SSL is disabled but
</pre>
</li>
</ol></li>
- <li><h4>Configuring Kafka Brokers</h4>
+ <li><h4><a id="security_sasl_brokerconfig" href="#security_sasl_brokerconfig">Configuring Kafka Brokers</a></h4>
<ol>
<li>Pass the name of the jaas file you created in <a href="#jaas_config_file">Creating JAAS Config File"</a> as a JVM parameter to the kafka broker: <pre>-Djava.security.auth.login.config=/etc/kafka/kafka_jaas.conf</pre></li>
<li>Make sure the keytabs configured in the kafka_jaas.conf are readable by the linux user who is starting kafka broker.</li>
@@ -248,11 +248,11 @@ Apache Kafka allows clients to connect over SSL. By default SSL is disabled but
</ol>
</li>
- <li><h4>Configuring Kafka Clients</h4>
+ <li><h4><a id="security_sasl_clientconfig" href="#security_sasl_clientconfig">Configuring Kafka Clients</a></h4>
SASL authentication is only supported for new kafka producer and consumer, the older API is not supported.>br>
To configure SASL authentication on the clients:
<ol>
- <li>pass the name of the jaas file you created in <a href="#jaas_client">Creating Client Side JAAS Config"</a> as a JVM parameter to the client JVM:
+ <li>pass the name of the jaas file you created in <a href="#security_sasl_jaas">Creating Client Side JAAS Config"</a> as a JVM parameter to the client JVM:
<pre>-Djava.security.auth.login.config=/etc/kafka/kafka_client_jaas.conf</pre></li>
<li>Make sure the keytabs configured in the kafka_client_jaas.conf are readable by the linux user who is starting kafka client.</li>
<li>Configure the following property in producer.properties or consumer.properties:
@@ -260,12 +260,15 @@ Apache Kafka allows clients to connect over SSL. By default SSL is disabled but
</ol></li>
</ol>
-<h3><a id="security_authz">7.4 Authorization and ACLs</a></h3>
+<h3><a id="security_authz" href="#security_authz">7.4 Authorization and ACLs</a></h3>
Kafka ships with a pluggable Authorizer and an out-of-box authorizer implementation that uses zookeeper to store all the acls. Kafka acls are defined in the general format of "Principal P is [Allowed/Denied] Operation O From Host H On Resource R". You can read more about the acl structure on KIP-11. In order to add, remove or list acls you can use the Kafka authorizer CLI. By default, if a Resource R has no associated acls, no one other than super users is allowed to access R. If you want change that behavior, you can include the following in broker.properties.
<pre>allow.everyone.if.no.acl.found=true</pre>
One can also add super users in broker.properties like the following.
<pre>super.users=User:Bob;User:Alice</pre>
-<h4>Command Line Interface</h4>
+By default, the SSL user name will be of the form "CN=writeuser,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown". One can change that by setting a customized PrincipalBuilder in broker.properties like the following.
+<pre>principal.builder.classs=CustomizedPrincipalBuilderClass</pre>
+By default, the SASL user name will be the primary part of the Kerberos principal. One can change that by setting <code>sasl.kerberos.principal.to.local.rules</code> to a customized rule in broker.properties.
+<h4><a id="security_authz_cli" href="#security_authz_cli">Command Line Interface</a></h4>
Kafka Authorization management CLI can be found under bin directory with all the other CLIs. The CLI script is called <b>kafka-acls.sh</b>. Following lists all the options that the script supports:
<p></p>
<table class="data-table">
@@ -336,20 +339,20 @@ Kafka Authorization management CLI can be found under bin directory with all the
<td>Principal</td>
</tr>
<tr>
- <td>--allow-hosts</td>
- <td>Comma separated list of hosts from which principals listed in --allow-principals will have access.</td>
+ <td>--allow-host</td>
+ <td>Host from which principals listed in --allow-principals will have access.</td>
<td> if --allow-principals is specified defaults to * which translates to "all hosts"</td>
<td>Host</td>
</tr>
<tr>
- <td>--deny-hosts</td>
- <td>Comma separated list of hosts from which principals listed in --deny-principals will be denied access.</td>
+ <td>--deny-host</td>
+ <td>Host from which principals listed in --deny-principals will be denied access.</td>
<td>if --deny-principals is specified defaults to * which translates to "all hosts"</td>
<td>Host</td>
</tr>
<tr>
- <td>--operations</td>
- <td>Comma separated list of operations.<br>
+ <td>--operation</td>
+ <td>Operation that will be allowed or denied.<br>
Valid values are : Read, Write, Create, Delete, Alter, Describe, ClusterAction, All</td>
<td>All</td>
<td>Operation</td>
@@ -369,18 +372,18 @@ Kafka Authorization management CLI can be found under bin directory with all the
</tr>
</tbody></table>
-<h4>Examples</h4>
+<h4><a id="security_authz_examples" href="#security_authz_examples">Examples</a></h4>
<ul>
<li><b>Adding Acls</b><br>
Suppose you want to add an acl "Principals User:Bob and User:Alice are allowed to perform Operation Read and Write on Topic Test-Topic from Host1 and Host2". You can do that by executing the CLI with following options:
- <pre>bin/kafka-acls.sh --authorizer kafka.security.auth.SimpleAclAuthorizer --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:Bob --allow-principal User:Alice --allow-hosts Host1,Host2 --operations Read,Write --topic Test-topic</pre>
- By default all principals that don't have an explicit acl that allows access for an operation to a resource are denied. In rare cases where an allow acl is defined that allows access to all but some principal we will have to use the --deny-principals and --deny-host option. For example, if we want to allow all users to Read from Test-topic but only deny User:BadBob from host bad-host we can do so using following commands:
- <pre>bin/kafka-acls.sh --authorizer kafka.security.auth.SimpleAclAuthorizer --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:* --allow-hosts * --deny-principal User:BadBob --deny-hosts bad-host --operations Read--topic Test-topic</pre>
+ <pre>bin/kafka-acls.sh --authorizer kafka.security.auth.SimpleAclAuthorizer --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:Bob --allow-principal User:Alice --allow-host Host1 --allow-host Host2 --operation Read --operation Write --topic Test-topic</pre>
+ By default all principals that don't have an explicit acl that allows access for an operation to a resource are denied. In rare cases where an allow acl is defined that allows access to all but some principal we will have to use the --deny-principal and --deny-host option. For example, if we want to allow all users to Read from Test-topic but only deny User:BadBob from host bad-host we can do so using following commands:
+ <pre>bin/kafka-acls.sh --authorizer kafka.security.auth.SimpleAclAuthorizer --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:* --allow-hosts * --deny-principal User:BadBob --deny-host bad-host --operation Read--topic Test-topic</pre>
Above examples add acls to a topic by specifying --topic [topic-name] as the resource option. Similarly user can add acls to cluster by specifying --cluster and to a consumer group by specifying --consumer-group [group-name].</li>
<li><b>Removing Acls</b><br>
Removing acls is pretty much the same. The only difference is instead of --add option users will have to specify --remove option. To remove the acls added by the first example above we can execute the CLI with following options:
- <pre> bin/kafka-acls.sh --authorizer kafka.security.auth.SimpleAclAuthorizer --authorizer-properties zookeeper.connect=localhost:2181 --remove --allow-principal User:Bob --allow-principal User:Alice --allow-hosts Host1,Host2 --operations Read,Write --topic Test-topic </pre></li>
+ <pre> bin/kafka-acls.sh --authorizer kafka.security.auth.SimpleAclAuthorizer --authorizer-properties zookeeper.connect=localhost:2181 --remove --allow-principal User:Bob --allow-principal User:Alice --allow-host Host1 --allow-host Host2 --operation Read --operation Write --topic Test-topic </pre></li>
<li><b>List Acls</b><br>
We can list acls for any resource by specifying the --list option with the resource. To list all acls for Test-topic we can execute the CLI with following options:
@@ -395,8 +398,8 @@ Suppose you want to add an acl "Principals User:Bob and User:Alice are allowed t
In order to remove a principal from producer or consumer role we just need to pass --remove option. </li>
</ul>
-<h3><a id="zk_authz">7.5 ZooKeeper Authentication</a></h3>
-<h4><a id="zk_authz_new">7.5.1 New clusters</a></h4>
+<h3><a id="zk_authz" href="#zk_authz">7.5 ZooKeeper Authentication</a></h3>
+<h4><a id="zk_authz_new" href="#zk_authz_new">7.5.1 New clusters</a></h4>
To enable ZooKeeper authentication on brokers, there are two necessary steps:
<ol>
<li> Create a JAAS login file and set the appropriate system property to point to it as described above</li>
@@ -405,7 +408,7 @@ To enable ZooKeeper authentication on brokers, there are two necessary steps:
The metadata stored in ZooKeeper is such that only brokers will be able to modify the corresponding znodes, but znodes are world readable. The rationale behind this decision is that the data stored in ZooKeeper is not sensitive, but inappropriate manipulation of znodes can cause cluster disruption.
-<h4><a id="zk_authz_migration">7.5.2 Migrating clusters</a></h4>
+<h4><a id="zk_authz_migration" href="#zk_authz_migration">7.5.2 Migrating clusters</a></h4>
If you are running a version of Kafka that does not support security of simply with security disabled, and you want to make the cluster secure, then you need to execute the following steps to enable ZooKeeper authentication with minimal disruption to your operations:
<ol>
<li>Perform a rolling restart setting the JAAS login file, which enables brokers to authenticate. At the end of the rolling restart, brokers are able to manipulate znodes with strict ACLs, but they will not create znodes with those ACLs</li>
@@ -426,7 +429,7 @@ Here is an example of how to run the migration tool:
<pre>
./bin/zookeeper-security-migration --help
</pre>
-<h4><a id="zk_authz_ensemble">7.5.3 Migrating the ZooKeeper ensemble</a></h4>
+<h4><a id="zk_authz_ensemble" href="#zk_authz_ensemble">7.5.3 Migrating the ZooKeeper ensemble</a></h4>
It is also necessary to enable authentication on the ZooKeeper ensemble. To do it, we need to perform a rolling restart of the server and set a few properties. Please refer to the ZooKeeper documentation for more detail:
<ol>
<li><a href="http://zookeeper.apache.org/doc/r3.4.6/zookeeperProgrammers.html#sc_ZooKeeperAccessControl">Apache ZooKeeper documentation</a></li>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/upgrade.html
----------------------------------------------------------------------
diff --git a/090/upgrade.html b/090/upgrade.html
index 3cf5aa1..704ec4f 100644
--- a/090/upgrade.html
+++ b/090/upgrade.html
@@ -15,9 +15,9 @@
limitations under the License.
-->
-<h3><a id="upgrade">1.5 Upgrading From Previous Versions</a></h3>
+<h3><a id="upgrade" href="#upgrade">1.5 Upgrading From Previous Versions</a></h3>
-<h4>Upgrading from 0.8.0, 0.8.1.X or 0.8.2.X to 0.9.0.0</h4>
+<h4><a id="upgrade_9" href="#upgrade_9">Upgrading from 0.8.0, 0.8.1.X or 0.8.2.X to 0.9.0.0</a></h4>
0.9.0.0 has an inter-broker protocol change from previous versions. For a rolling upgrade:
<ol>
@@ -31,7 +31,7 @@ Note: If you are willing to accept downtime, you can simply take all the brokers
Note: Bumping the protocol version and restarting can be done any time after the brokers were upgraded. It does not have to be immediately after.
-<h5>Potential breaking changes in 0.9.0.0</h5>
+<h5><a id="upgrade_9_breaking" href="#upgrade_9_breaking">Potential breaking changes in 0.9.0.0</a></h5>
<ul>
<li> Java 1.6 is no longer supported. </li>
@@ -52,14 +52,14 @@ Note: Bumping the protocol version and restarting can be done any time after the
<li> The kafka.tools.ProducerPerformance class has been deprecated. Going forward, please use org.apache.kafka.tools.ProducerPerformance for this functionality (kafka-producer-perf-test.sh will also be changed to use the new class). </li>
</ul>
-<h4>Upgrading from 0.8.1 to 0.8.2</h4>
+<h4><a id="upgrade_82" href="#upgrade_82">Upgrading from 0.8.1 to 0.8.2</a></h4>
0.8.2 is fully compatible with 0.8.1. The upgrade can be done one broker at a time by simply bringing it down, updating the code, and restarting it.
-<h4>Upgrading from 0.8.0 to 0.8.1</h4>
+<h4><a id="upgrade_81" href="#upgrade_81">Upgrading from 0.8.0 to 0.8.1</a></h4>
0.8.1 is fully compatible with 0.8. The upgrade can be done one broker at a time by simply bringing it down, updating the code, and restarting it.
-<h4>Upgrading from 0.7</h4>
+<h4><a id="upgrade_7" href="#upgrade_7">Upgrading from 0.7</a></h4>
Release 0.7 is incompatible with newer releases. Major changes were made to the API, ZooKeeper data structures, and protocol, and configuration in order to add replication (Which was missing in 0.7). The upgrade from 0.7 to later versions requires a <a href="https://cwiki.apache.org/confluence/display/KAFKA/Migrating+from+0.7+to+0.8">special tool</a> for migration. This migration can be done without downtime.
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/uses.html
----------------------------------------------------------------------
diff --git a/090/uses.html b/090/uses.html
index aa87d07..f769bed 100644
--- a/090/uses.html
+++ b/090/uses.html
@@ -5,9 +5,9 @@
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
-
+
http://www.apache.org/licenses/LICENSE-2.0
-
+
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -15,11 +15,11 @@
limitations under the License.
-->
-<h3><a id="uses">1.2 Use Cases</a></h3>
+<h3><a id="uses" href="#uses">1.2 Use Cases</a></h3>
Here is a description of a few of the popular use cases for Apache Kafka. For an overview of a number of these areas in action, see <a href="http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying">this blog post</a>.
-<h4>Messaging</h4>
+<h4><a id="uses_messaging" href="#uses_messaging">Messaging</a></h4>
Kafka works well as a replacement for a more traditional message broker. Message brokers are used for a variety of reasons (to decouple processing from data producers, to buffer unprocessed messages, etc). In comparison to most messaging systems Kafka has better throughput, built-in partitioning, replication, and fault-tolerance which makes it a good solution for large scale message processing applications.
<p>
@@ -27,30 +27,30 @@ In our experience messaging uses are often comparatively low-throughput, but may
<p>
In this domain Kafka is comparable to traditional messaging systems such as <a href="http://activemq.apache.org">ActiveMQ</a> or <a href="https://www.rabbitmq.com">RabbitMQ</a>.
-<h4>Website Activity Tracking</h4>
+<h4><a id="uses_website" href="#uses_website">Website Activity Tracking</a></h4>
The original use case for Kafka was to be able to rebuild a user activity tracking pipeline as a set of real-time publish-subscribe feeds. This means site activity (page views, searches, or other actions users may take) is published to central topics with one topic per activity type. These feeds are available for subscription for a range of use cases including real-time processing, real-time monitoring, and loading into Hadoop or offline data warehousing systems for offline processing and reporting.
<p>
Activity tracking is often very high volume as many activity messages are generated for each user page view.
-<h4>Metrics</h4>
+<h4><a id="uses_metrics" href="#uses_metrics">Metrics</a></h4>
Kafka is often used for operational monitoring data. This involves aggregating statistics from distributed applications to produce centralized feeds of operational data.
-<h4>Log Aggregation</h4>
+<h4><a id="uses_logs" href="#uses_logs">Log Aggregation</a></h4>
Many people use Kafka as a replacement for a log aggregation solution. Log aggregation typically collects physical log files off servers and puts them in a central place (a file server or HDFS perhaps) for processing. Kafka abstracts away the details of files and gives a cleaner abstraction of log or event data as a stream of messages. This allows for lower-latency processing and easier support for multiple data sources and distributed data consumption.
In comparison to log-centric systems like Scribe or Flume, Kafka offers equally good performance, stronger durability guarantees due to replication, and much lower end-to-end latency.
-<h4>Stream Processing</h4>
+<h4><a id="uses_streamprocessing" href="#uses_streamprocessing">Stream Processing</a></h4>
Many users end up doing stage-wise processing of data where data is consumed from topics of raw data and then aggregated, enriched, or otherwise transformed into new Kafka topics for further consumption. For example a processing flow for article recommendation might crawl article content from RSS feeds and publish it to an "articles" topic; further processing might help normalize or deduplicate this content to a topic of cleaned article content; a final stage might attempt to match this content to users. This creates a graph of real-time data flow out of the individual topics. <a href="https://storm.apache.org/">Storm</a> and <a href="http://samza.apache.org/">Samza</a> are popular frameworks for implementing these kinds of transformations.
-<h4>Event Sourcing</h4>
+<h4><a id="uses_eventsourcing" href="#uses_eventsourcing">Event Sourcing</a></h4>
<a href="http://martinfowler.com/eaaDev/EventSourcing.html">Event sourcing</a> is a style of application design where state changes are logged as a time-ordered sequence of records. Kafka's support for very large stored log data makes it an excellent backend for an application built in this style.
-<h4>Commit Log</h4>
+<h4><a id="uses_commitlog" href="#uses_commitlog">Commit Log</a></h4>
Kafka can serve as a kind of external commit-log for a distributed system. The log helps replicate data between nodes and acts as a re-syncing mechanism for failed nodes to restore their data. The <a href="/documentation.html#compaction">log compaction</a> feature in Kafka helps support this usage. In this usage Kafka is similar to <a href="http://zookeeper.apache.org/bookkeeper/">Apache BookKeeper</a> project.
[2/3] kafka-site git commit: upload latest 0.9.0 docs
Posted by ju...@apache.org.
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/introduction.html
----------------------------------------------------------------------
diff --git a/090/introduction.html b/090/introduction.html
index 7e0b150..e5b2e78 100644
--- a/090/introduction.html
+++ b/090/introduction.html
@@ -5,9 +5,9 @@
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
-
+
http://www.apache.org/licenses/LICENSE-2.0
-
+
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -15,7 +15,7 @@
limitations under the License.
-->
-<h3><a id="introduction">1.1 Introduction</a></h3>
+<h3><a id="introduction" href="#introduction">1.1 Introduction</a></h3>
Kafka is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system, but with a unique design.
<p>
What does all that mean?
@@ -35,7 +35,7 @@ So, at a high level, producers send messages over the network to the Kafka clust
Communication between the clients and the servers is done with a simple, high-performance, language agnostic <a href="https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Protocol">TCP protocol</a>. We provide a Java client for Kafka, but clients are available in <a href="https://cwiki.apache.org/confluence/display/KAFKA/Clients">many languages</a>.
-<h4>Topics and Logs</h4>
+<h4><a id="intro_topics" href="#intro_topics">Topics and Logs</a></h4>
Let's first dive into the high-level abstraction Kafka provides—the topic.
<p>
A topic is a category or feed name to which messages are published. For each topic, the Kafka cluster maintains a partitioned log that looks like this:
@@ -50,19 +50,19 @@ In fact the only metadata retained on a per-consumer basis is the position of th
<p>
This combination of features means that Kafka consumers are very cheap—they can come and go without much impact on the cluster or on other consumers. For example, you can use our command line tools to "tail" the contents of any topic without changing what is consumed by any existing consumers.
<p>
-The partitions in the log serve several purposes. First, they allow the log to scale beyond a size that will fit on a single server. Each individual partition must fit on the servers that host it, but a topic may have many partitions so it can handle an arbitrary amount of data. Second they act as the unit of parallelism—more on that in a bit.
+The partitions in the log serve several purposes. First, they allow the log to scale beyond a size that will fit on a single server. Each individual partition must fit on the servers that host it, but a topic may have many partitions so it can handle an arbitrary amount of data. Second they act as the unit of parallelism—more on that in a bit.
-<h4>Distribution</h4>
+<h4><a id="intro_distribution" href="#intro_distribution">Distribution</a></h4>
The partitions of the log are distributed over the servers in the Kafka cluster with each server handling data and requests for a share of the partitions. Each partition is replicated across a configurable number of servers for fault tolerance.
<p>
Each partition has one server which acts as the "leader" and zero or more servers which act as "followers". The leader handles all read and write requests for the partition while the followers passively replicate the leader. If the leader fails, one of the followers will automatically become the new leader. Each server acts as a leader for some of its partitions and a follower for others so load is well balanced within the cluster.
-<h4>Producers</h4>
+<h4><a id="intro_producers" href="#intro_producers">Producers</a></h4>
Producers publish data to the topics of their choice. The producer is responsible for choosing which message to assign to which partition within the topic. This can be done in a round-robin fashion simply to balance load or it can be done according to some semantic partition function (say based on some key in the message). More on the use of partitioning in a second.
-<h4><a id="intro_consumers">Consumers</a></h4>
+<h4><a id="intro_consumers" href="#intro_consumers">Consumers</a></h4>
Messaging traditionally has two models: <a href="http://en.wikipedia.org/wiki/Message_queue">queuing</a> and <a href="http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern">publish-subscribe</a>. In a queue, a pool of consumers may read from a server and each message goes to one of them; in publish-subscribe the message is broadcast to all consumers. Kafka offers a single consumer abstraction that generalizes both of these—the <i>consumer group</i>.
<p>
@@ -70,7 +70,7 @@ Consumers label themselves with a consumer group name, and each message publishe
<p>
If all the consumer instances have the same consumer group, then this works just like a traditional queue balancing load over the consumers.
<p>
-If all the consumer instances have different consumer groups, then this works like publish-subscribe and all messages are broadcast to all consumers.
+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.
<p>
@@ -88,7 +88,7 @@ Kafka does it better. By having a notion of parallelism—the partition&mdas
<p>
Kafka only provides a total order over messages <i>within</i> a partition, not between different partitions in a topic. Per-partition ordering combined with the ability to partition data by key is sufficient for most applications. However, if you require a total order over messages this can be achieved with a topic that has only one partition, though this will mean only one consumer process per consumer group.
-<h4>Guarantees</h4>
+<h4><a id="intro_guarantees" href="#intro_guarantees">Guarantees</a></h4>
At a high-level Kafka gives the following guarantees:
<ul>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/allclasses-frame.html
----------------------------------------------------------------------
diff --git a/090/javadoc/allclasses-frame.html b/090/javadoc/allclasses-frame.html
index b5d3709..b8ef929 100644
--- a/090/javadoc/allclasses-frame.html
+++ b/090/javadoc/allclasses-frame.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>All Classes (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/allclasses-noframe.html
----------------------------------------------------------------------
diff --git a/090/javadoc/allclasses-noframe.html b/090/javadoc/allclasses-noframe.html
index 3773f1e..d32d5ec 100644
--- a/090/javadoc/allclasses-noframe.html
+++ b/090/javadoc/allclasses-noframe.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>All Classes (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/constant-values.html
----------------------------------------------------------------------
diff --git a/090/javadoc/constant-values.html b/090/javadoc/constant-values.html
index 81b3a24..0d4f67f 100644
--- a/090/javadoc/constant-values.html
+++ b/090/javadoc/constant-values.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>Constant Field Values (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/deprecated-list.html
----------------------------------------------------------------------
diff --git a/090/javadoc/deprecated-list.html b/090/javadoc/deprecated-list.html
index fb02875..ecbc175 100644
--- a/090/javadoc/deprecated-list.html
+++ b/090/javadoc/deprecated-list.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>Deprecated List (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/help-doc.html
----------------------------------------------------------------------
diff --git a/090/javadoc/help-doc.html b/090/javadoc/help-doc.html
index 26b4d53..10f17da 100644
--- a/090/javadoc/help-doc.html
+++ b/090/javadoc/help-doc.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>API Help (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/index-all.html
----------------------------------------------------------------------
diff --git a/090/javadoc/index-all.html b/090/javadoc/index-all.html
index 77d62e3..70c568c 100644
--- a/090/javadoc/index-all.html
+++ b/090/javadoc/index-all.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>Index (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="./stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/index.html
----------------------------------------------------------------------
diff --git a/090/javadoc/index.html b/090/javadoc/index.html
index fe328eb..c9aeb10 100644
--- a/090/javadoc/index.html
+++ b/090/javadoc/index.html
@@ -2,7 +2,7 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc on Tue Nov 17 18:38:11 PST 2015 -->
<title>clients 0.9.0.0 API</title>
<script type="text/javascript">
targetPage = "" + window.location.search;
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/CommitFailedException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/CommitFailedException.html b/090/javadoc/org/apache/kafka/clients/consumer/CommitFailedException.html
index a7015f7..a7ed4db 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/CommitFailedException.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/CommitFailedException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:04 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:09 PST 2015 -->
<title>CommitFailedException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/Consumer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/Consumer.html b/090/javadoc/org/apache/kafka/clients/consumer/Consumer.html
index f7ed059..1c3de20 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/Consumer.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/Consumer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:04 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:09 PST 2015 -->
<title>Consumer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/ConsumerConfig.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/ConsumerConfig.html b/090/javadoc/org/apache/kafka/clients/consumer/ConsumerConfig.html
index 3e265ac..34960e0 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/ConsumerConfig.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/ConsumerConfig.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:04 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:09 PST 2015 -->
<title>ConsumerConfig (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRebalanceListener.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRebalanceListener.html b/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRebalanceListener.html
index 06f3120..6e771db 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRebalanceListener.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRebalanceListener.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:09 PST 2015 -->
<title>ConsumerRebalanceListener (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRecord.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRecord.html b/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRecord.html
index 1f78cd0..69257f3 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRecord.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRecord.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:09 PST 2015 -->
<title>ConsumerRecord (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRecords.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRecords.html b/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRecords.html
index 91d5bdd..d3d7b43 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRecords.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/ConsumerRecords.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:09 PST 2015 -->
<title>ConsumerRecords (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/InvalidOffsetException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/InvalidOffsetException.html b/090/javadoc/org/apache/kafka/clients/consumer/InvalidOffsetException.html
index 83712e4..5df3d7d 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/InvalidOffsetException.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/InvalidOffsetException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:09 PST 2015 -->
<title>InvalidOffsetException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html b/090/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html
index a9f9789..3cbad8b 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/KafkaConsumer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>KafkaConsumer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/MockConsumer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/MockConsumer.html b/090/javadoc/org/apache/kafka/clients/consumer/MockConsumer.html
index fde12c9..cf5503c 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/MockConsumer.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/MockConsumer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>MockConsumer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/NoOffsetForPartitionException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/NoOffsetForPartitionException.html b/090/javadoc/org/apache/kafka/clients/consumer/NoOffsetForPartitionException.html
index 1598aa9..9f7402e 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/NoOffsetForPartitionException.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/NoOffsetForPartitionException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>NoOffsetForPartitionException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/OffsetAndMetadata.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/OffsetAndMetadata.html b/090/javadoc/org/apache/kafka/clients/consumer/OffsetAndMetadata.html
index 6490db1..b76a3f7 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/OffsetAndMetadata.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/OffsetAndMetadata.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>OffsetAndMetadata (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/OffsetCommitCallback.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/OffsetCommitCallback.html b/090/javadoc/org/apache/kafka/clients/consumer/OffsetCommitCallback.html
index 34d1bf1..be97c24 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/OffsetCommitCallback.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/OffsetCommitCallback.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>OffsetCommitCallback (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/OffsetOutOfRangeException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/OffsetOutOfRangeException.html b/090/javadoc/org/apache/kafka/clients/consumer/OffsetOutOfRangeException.html
index 87a3144..bdcf3fb 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/OffsetOutOfRangeException.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/OffsetOutOfRangeException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>OffsetOutOfRangeException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/OffsetResetStrategy.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/OffsetResetStrategy.html b/090/javadoc/org/apache/kafka/clients/consumer/OffsetResetStrategy.html
index f053337..7307987 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/OffsetResetStrategy.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/OffsetResetStrategy.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>OffsetResetStrategy (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/RangeAssignor.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/RangeAssignor.html b/090/javadoc/org/apache/kafka/clients/consumer/RangeAssignor.html
index 8b9a21b..8488948 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/RangeAssignor.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/RangeAssignor.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>RangeAssignor (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/RoundRobinAssignor.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/RoundRobinAssignor.html b/090/javadoc/org/apache/kafka/clients/consumer/RoundRobinAssignor.html
index c775c1a..7b0eb93 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/RoundRobinAssignor.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/RoundRobinAssignor.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>RoundRobinAssignor (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/package-frame.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/package-frame.html b/090/javadoc/org/apache/kafka/clients/consumer/package-frame.html
index 5b1851c..d2f9884 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/package-frame.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/package-frame.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.clients.consumer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/package-summary.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/package-summary.html b/090/javadoc/org/apache/kafka/clients/consumer/package-summary.html
index 1d79891..6c6f14c 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/package-summary.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/package-summary.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.clients.consumer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/consumer/package-tree.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/consumer/package-tree.html b/090/javadoc/org/apache/kafka/clients/consumer/package-tree.html
index a55d3d7..7210ce0 100644
--- a/090/javadoc/org/apache/kafka/clients/consumer/package-tree.html
+++ b/090/javadoc/org/apache/kafka/clients/consumer/package-tree.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.clients.consumer Class Hierarchy (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/producer/BufferExhaustedException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/producer/BufferExhaustedException.html b/090/javadoc/org/apache/kafka/clients/producer/BufferExhaustedException.html
index f301ee5..06f1c90 100644
--- a/090/javadoc/org/apache/kafka/clients/producer/BufferExhaustedException.html
+++ b/090/javadoc/org/apache/kafka/clients/producer/BufferExhaustedException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>BufferExhaustedException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/producer/Callback.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/producer/Callback.html b/090/javadoc/org/apache/kafka/clients/producer/Callback.html
index 9d8bddc..f0f4327 100644
--- a/090/javadoc/org/apache/kafka/clients/producer/Callback.html
+++ b/090/javadoc/org/apache/kafka/clients/producer/Callback.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>Callback (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/producer/KafkaProducer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/producer/KafkaProducer.html b/090/javadoc/org/apache/kafka/clients/producer/KafkaProducer.html
index 6544c17..25b0689 100644
--- a/090/javadoc/org/apache/kafka/clients/producer/KafkaProducer.html
+++ b/090/javadoc/org/apache/kafka/clients/producer/KafkaProducer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>KafkaProducer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/producer/MockProducer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/producer/MockProducer.html b/090/javadoc/org/apache/kafka/clients/producer/MockProducer.html
index e0625ea..1ea145f 100644
--- a/090/javadoc/org/apache/kafka/clients/producer/MockProducer.html
+++ b/090/javadoc/org/apache/kafka/clients/producer/MockProducer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>MockProducer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/producer/Partitioner.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/producer/Partitioner.html b/090/javadoc/org/apache/kafka/clients/producer/Partitioner.html
index a857049..a40f1fb 100644
--- a/090/javadoc/org/apache/kafka/clients/producer/Partitioner.html
+++ b/090/javadoc/org/apache/kafka/clients/producer/Partitioner.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>Partitioner (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/producer/Producer.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/producer/Producer.html b/090/javadoc/org/apache/kafka/clients/producer/Producer.html
index 006a81c..3d0e610 100644
--- a/090/javadoc/org/apache/kafka/clients/producer/Producer.html
+++ b/090/javadoc/org/apache/kafka/clients/producer/Producer.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>Producer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/producer/ProducerConfig.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/producer/ProducerConfig.html b/090/javadoc/org/apache/kafka/clients/producer/ProducerConfig.html
index d66b0a1..274d704 100644
--- a/090/javadoc/org/apache/kafka/clients/producer/ProducerConfig.html
+++ b/090/javadoc/org/apache/kafka/clients/producer/ProducerConfig.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>ProducerConfig (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/producer/ProducerRecord.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/producer/ProducerRecord.html b/090/javadoc/org/apache/kafka/clients/producer/ProducerRecord.html
index 7ffef67..a7519bd 100644
--- a/090/javadoc/org/apache/kafka/clients/producer/ProducerRecord.html
+++ b/090/javadoc/org/apache/kafka/clients/producer/ProducerRecord.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>ProducerRecord (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/producer/RecordMetadata.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/producer/RecordMetadata.html b/090/javadoc/org/apache/kafka/clients/producer/RecordMetadata.html
index 4e288d7..d0bb99e 100644
--- a/090/javadoc/org/apache/kafka/clients/producer/RecordMetadata.html
+++ b/090/javadoc/org/apache/kafka/clients/producer/RecordMetadata.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>RecordMetadata (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/producer/package-frame.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/producer/package-frame.html b/090/javadoc/org/apache/kafka/clients/producer/package-frame.html
index 746ca0f..f4df1ad 100644
--- a/090/javadoc/org/apache/kafka/clients/producer/package-frame.html
+++ b/090/javadoc/org/apache/kafka/clients/producer/package-frame.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.clients.producer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/producer/package-summary.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/producer/package-summary.html b/090/javadoc/org/apache/kafka/clients/producer/package-summary.html
index bce6281..d99b877 100644
--- a/090/javadoc/org/apache/kafka/clients/producer/package-summary.html
+++ b/090/javadoc/org/apache/kafka/clients/producer/package-summary.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.clients.producer (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/clients/producer/package-tree.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/clients/producer/package-tree.html b/090/javadoc/org/apache/kafka/clients/producer/package-tree.html
index b37afbd..95121fc 100644
--- a/090/javadoc/org/apache/kafka/clients/producer/package-tree.html
+++ b/090/javadoc/org/apache/kafka/clients/producer/package-tree.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.clients.producer Class Hierarchy (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/Cluster.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/Cluster.html b/090/javadoc/org/apache/kafka/common/Cluster.html
index f7d5997..ad24c66 100644
--- a/090/javadoc/org/apache/kafka/common/Cluster.html
+++ b/090/javadoc/org/apache/kafka/common/Cluster.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>Cluster (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/Configurable.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/Configurable.html b/090/javadoc/org/apache/kafka/common/Configurable.html
index 51044e5..caecfc8 100644
--- a/090/javadoc/org/apache/kafka/common/Configurable.html
+++ b/090/javadoc/org/apache/kafka/common/Configurable.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>Configurable (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/KafkaException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/KafkaException.html b/090/javadoc/org/apache/kafka/common/KafkaException.html
index ed1a49a..042e8fa 100644
--- a/090/javadoc/org/apache/kafka/common/KafkaException.html
+++ b/090/javadoc/org/apache/kafka/common/KafkaException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>KafkaException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/Metric.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/Metric.html b/090/javadoc/org/apache/kafka/common/Metric.html
index d799555..23381dc 100644
--- a/090/javadoc/org/apache/kafka/common/Metric.html
+++ b/090/javadoc/org/apache/kafka/common/Metric.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>Metric (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/MetricName.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/MetricName.html b/090/javadoc/org/apache/kafka/common/MetricName.html
index 8f0ed79..e8e2b1f 100644
--- a/090/javadoc/org/apache/kafka/common/MetricName.html
+++ b/090/javadoc/org/apache/kafka/common/MetricName.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>MetricName (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/Node.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/Node.html b/090/javadoc/org/apache/kafka/common/Node.html
index 9a16521..def15f9 100644
--- a/090/javadoc/org/apache/kafka/common/Node.html
+++ b/090/javadoc/org/apache/kafka/common/Node.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>Node (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/PartitionInfo.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/PartitionInfo.html b/090/javadoc/org/apache/kafka/common/PartitionInfo.html
index 8bf5f95..5af6dd0 100644
--- a/090/javadoc/org/apache/kafka/common/PartitionInfo.html
+++ b/090/javadoc/org/apache/kafka/common/PartitionInfo.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>PartitionInfo (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/TopicPartition.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/TopicPartition.html b/090/javadoc/org/apache/kafka/common/TopicPartition.html
index f336a37..9165439 100644
--- a/090/javadoc/org/apache/kafka/common/TopicPartition.html
+++ b/090/javadoc/org/apache/kafka/common/TopicPartition.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>TopicPartition (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/ApiException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/ApiException.html b/090/javadoc/org/apache/kafka/common/errors/ApiException.html
index c0ce8ec..d4ace34 100644
--- a/090/javadoc/org/apache/kafka/common/errors/ApiException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/ApiException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>ApiException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/AuthorizationException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/AuthorizationException.html b/090/javadoc/org/apache/kafka/common/errors/AuthorizationException.html
index e8fba02..6a89cf0 100644
--- a/090/javadoc/org/apache/kafka/common/errors/AuthorizationException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/AuthorizationException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>AuthorizationException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/BrokerNotAvailableException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/BrokerNotAvailableException.html b/090/javadoc/org/apache/kafka/common/errors/BrokerNotAvailableException.html
index f348fcf..220d260 100644
--- a/090/javadoc/org/apache/kafka/common/errors/BrokerNotAvailableException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/BrokerNotAvailableException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>BrokerNotAvailableException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/ControllerMovedException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/ControllerMovedException.html b/090/javadoc/org/apache/kafka/common/errors/ControllerMovedException.html
index 7b0f5b8..e07526e 100644
--- a/090/javadoc/org/apache/kafka/common/errors/ControllerMovedException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/ControllerMovedException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>ControllerMovedException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/CorruptRecordException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/CorruptRecordException.html b/090/javadoc/org/apache/kafka/common/errors/CorruptRecordException.html
index 0d2f342..dd13ad7 100644
--- a/090/javadoc/org/apache/kafka/common/errors/CorruptRecordException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/CorruptRecordException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>CorruptRecordException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/DisconnectException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/DisconnectException.html b/090/javadoc/org/apache/kafka/common/errors/DisconnectException.html
index b418fb3..32d11a6 100644
--- a/090/javadoc/org/apache/kafka/common/errors/DisconnectException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/DisconnectException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>DisconnectException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/GroupAuthorizationException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/GroupAuthorizationException.html b/090/javadoc/org/apache/kafka/common/errors/GroupAuthorizationException.html
index 062be01..6c5b312 100644
--- a/090/javadoc/org/apache/kafka/common/errors/GroupAuthorizationException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/GroupAuthorizationException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>GroupAuthorizationException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/GroupCoordinatorNotAvailableException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/GroupCoordinatorNotAvailableException.html b/090/javadoc/org/apache/kafka/common/errors/GroupCoordinatorNotAvailableException.html
index a5b3545..ddfc782 100644
--- a/090/javadoc/org/apache/kafka/common/errors/GroupCoordinatorNotAvailableException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/GroupCoordinatorNotAvailableException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>GroupCoordinatorNotAvailableException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/GroupLoadInProgressException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/GroupLoadInProgressException.html b/090/javadoc/org/apache/kafka/common/errors/GroupLoadInProgressException.html
index cb225e4..4108df1 100644
--- a/090/javadoc/org/apache/kafka/common/errors/GroupLoadInProgressException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/GroupLoadInProgressException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>GroupLoadInProgressException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/IllegalGenerationException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/IllegalGenerationException.html b/090/javadoc/org/apache/kafka/common/errors/IllegalGenerationException.html
index b7b3221..750a4eb 100644
--- a/090/javadoc/org/apache/kafka/common/errors/IllegalGenerationException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/IllegalGenerationException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>IllegalGenerationException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/InterruptException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/InterruptException.html b/090/javadoc/org/apache/kafka/common/errors/InterruptException.html
index 237a20e..52e014c 100644
--- a/090/javadoc/org/apache/kafka/common/errors/InterruptException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/InterruptException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>InterruptException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/InvalidMetadataException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/InvalidMetadataException.html b/090/javadoc/org/apache/kafka/common/errors/InvalidMetadataException.html
index be529a8..e1e645f 100644
--- a/090/javadoc/org/apache/kafka/common/errors/InvalidMetadataException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/InvalidMetadataException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>InvalidMetadataException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/InvalidRequiredAcksException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/InvalidRequiredAcksException.html b/090/javadoc/org/apache/kafka/common/errors/InvalidRequiredAcksException.html
index 6ed3e2e..e1f312c 100644
--- a/090/javadoc/org/apache/kafka/common/errors/InvalidRequiredAcksException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/InvalidRequiredAcksException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>InvalidRequiredAcksException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/InvalidTopicException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/InvalidTopicException.html b/090/javadoc/org/apache/kafka/common/errors/InvalidTopicException.html
index ac8319d..6588310 100644
--- a/090/javadoc/org/apache/kafka/common/errors/InvalidTopicException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/InvalidTopicException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>InvalidTopicException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/LeaderNotAvailableException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/LeaderNotAvailableException.html b/090/javadoc/org/apache/kafka/common/errors/LeaderNotAvailableException.html
index 93916f0..97b1ac7 100644
--- a/090/javadoc/org/apache/kafka/common/errors/LeaderNotAvailableException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/LeaderNotAvailableException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>LeaderNotAvailableException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/NetworkException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/NetworkException.html b/090/javadoc/org/apache/kafka/common/errors/NetworkException.html
index 238aa88..3185cac 100644
--- a/090/javadoc/org/apache/kafka/common/errors/NetworkException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/NetworkException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>NetworkException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/NotCoordinatorForGroupException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/NotCoordinatorForGroupException.html b/090/javadoc/org/apache/kafka/common/errors/NotCoordinatorForGroupException.html
index b14929e..5940ccd 100644
--- a/090/javadoc/org/apache/kafka/common/errors/NotCoordinatorForGroupException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/NotCoordinatorForGroupException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>NotCoordinatorForGroupException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/NotEnoughReplicasAfterAppendException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/NotEnoughReplicasAfterAppendException.html b/090/javadoc/org/apache/kafka/common/errors/NotEnoughReplicasAfterAppendException.html
index c87e902..d407621 100644
--- a/090/javadoc/org/apache/kafka/common/errors/NotEnoughReplicasAfterAppendException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/NotEnoughReplicasAfterAppendException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>NotEnoughReplicasAfterAppendException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/NotEnoughReplicasException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/NotEnoughReplicasException.html b/090/javadoc/org/apache/kafka/common/errors/NotEnoughReplicasException.html
index 2ceb767..9e9e121 100644
--- a/090/javadoc/org/apache/kafka/common/errors/NotEnoughReplicasException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/NotEnoughReplicasException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>NotEnoughReplicasException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/NotLeaderForPartitionException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/NotLeaderForPartitionException.html b/090/javadoc/org/apache/kafka/common/errors/NotLeaderForPartitionException.html
index 6a1e563..70576e8 100644
--- a/090/javadoc/org/apache/kafka/common/errors/NotLeaderForPartitionException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/NotLeaderForPartitionException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>NotLeaderForPartitionException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/OffsetMetadataTooLarge.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/OffsetMetadataTooLarge.html b/090/javadoc/org/apache/kafka/common/errors/OffsetMetadataTooLarge.html
index ec48dbe..bf2432d 100644
--- a/090/javadoc/org/apache/kafka/common/errors/OffsetMetadataTooLarge.html
+++ b/090/javadoc/org/apache/kafka/common/errors/OffsetMetadataTooLarge.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>OffsetMetadataTooLarge (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/RebalanceInProgressException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/RebalanceInProgressException.html b/090/javadoc/org/apache/kafka/common/errors/RebalanceInProgressException.html
index 37d2a00..2f052ba 100644
--- a/090/javadoc/org/apache/kafka/common/errors/RebalanceInProgressException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/RebalanceInProgressException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>RebalanceInProgressException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/RecordBatchTooLargeException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/RecordBatchTooLargeException.html b/090/javadoc/org/apache/kafka/common/errors/RecordBatchTooLargeException.html
index 51f3dc0..34e603c 100644
--- a/090/javadoc/org/apache/kafka/common/errors/RecordBatchTooLargeException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/RecordBatchTooLargeException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>RecordBatchTooLargeException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/RecordTooLargeException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/RecordTooLargeException.html b/090/javadoc/org/apache/kafka/common/errors/RecordTooLargeException.html
index a535c79..cfabaf5 100644
--- a/090/javadoc/org/apache/kafka/common/errors/RecordTooLargeException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/RecordTooLargeException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>RecordTooLargeException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/RetriableException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/RetriableException.html b/090/javadoc/org/apache/kafka/common/errors/RetriableException.html
index afba605..f3530d1 100644
--- a/090/javadoc/org/apache/kafka/common/errors/RetriableException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/RetriableException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>RetriableException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/SerializationException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/SerializationException.html b/090/javadoc/org/apache/kafka/common/errors/SerializationException.html
index 5106f11..6b96054 100644
--- a/090/javadoc/org/apache/kafka/common/errors/SerializationException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/SerializationException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>SerializationException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/TimeoutException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/TimeoutException.html b/090/javadoc/org/apache/kafka/common/errors/TimeoutException.html
index d8c834c..aea7964 100644
--- a/090/javadoc/org/apache/kafka/common/errors/TimeoutException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/TimeoutException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>TimeoutException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/TopicAuthorizationException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/TopicAuthorizationException.html b/090/javadoc/org/apache/kafka/common/errors/TopicAuthorizationException.html
index 8c1334d..e71c3fb 100644
--- a/090/javadoc/org/apache/kafka/common/errors/TopicAuthorizationException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/TopicAuthorizationException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>TopicAuthorizationException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/UnknownMemberIdException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/UnknownMemberIdException.html b/090/javadoc/org/apache/kafka/common/errors/UnknownMemberIdException.html
index d767413..37257dd 100644
--- a/090/javadoc/org/apache/kafka/common/errors/UnknownMemberIdException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/UnknownMemberIdException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>UnknownMemberIdException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/UnknownServerException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/UnknownServerException.html b/090/javadoc/org/apache/kafka/common/errors/UnknownServerException.html
index 9dca82a..9362236 100644
--- a/090/javadoc/org/apache/kafka/common/errors/UnknownServerException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/UnknownServerException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>UnknownServerException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/UnknownTopicOrPartitionException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/UnknownTopicOrPartitionException.html b/090/javadoc/org/apache/kafka/common/errors/UnknownTopicOrPartitionException.html
index dfdc58e..0ee38ae 100644
--- a/090/javadoc/org/apache/kafka/common/errors/UnknownTopicOrPartitionException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/UnknownTopicOrPartitionException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>UnknownTopicOrPartitionException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/WakeupException.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/WakeupException.html b/090/javadoc/org/apache/kafka/common/errors/WakeupException.html
index 004a362..1f29f49 100644
--- a/090/javadoc/org/apache/kafka/common/errors/WakeupException.html
+++ b/090/javadoc/org/apache/kafka/common/errors/WakeupException.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:05 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:10 PST 2015 -->
<title>WakeupException (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/package-frame.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/package-frame.html b/090/javadoc/org/apache/kafka/common/errors/package-frame.html
index 8a2747c..56c906d 100644
--- a/090/javadoc/org/apache/kafka/common/errors/package-frame.html
+++ b/090/javadoc/org/apache/kafka/common/errors/package-frame.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.common.errors (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/package-summary.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/package-summary.html b/090/javadoc/org/apache/kafka/common/errors/package-summary.html
index 63c5993..333015b 100644
--- a/090/javadoc/org/apache/kafka/common/errors/package-summary.html
+++ b/090/javadoc/org/apache/kafka/common/errors/package-summary.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.common.errors (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/errors/package-tree.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/errors/package-tree.html b/090/javadoc/org/apache/kafka/common/errors/package-tree.html
index 5ae3791..48a4772 100644
--- a/090/javadoc/org/apache/kafka/common/errors/package-tree.html
+++ b/090/javadoc/org/apache/kafka/common/errors/package-tree.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.common.errors Class Hierarchy (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/package-frame.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/package-frame.html b/090/javadoc/org/apache/kafka/common/package-frame.html
index 87bd6a3..ae20127 100644
--- a/090/javadoc/org/apache/kafka/common/package-frame.html
+++ b/090/javadoc/org/apache/kafka/common/package-frame.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.common (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/package-summary.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/package-summary.html b/090/javadoc/org/apache/kafka/common/package-summary.html
index 0936067..e4d6d9f 100644
--- a/090/javadoc/org/apache/kafka/common/package-summary.html
+++ b/090/javadoc/org/apache/kafka/common/package-summary.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.common (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../stylesheet.css" title="Style">
</head>
<body>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/javadoc/org/apache/kafka/common/package-tree.html
----------------------------------------------------------------------
diff --git a/090/javadoc/org/apache/kafka/common/package-tree.html b/090/javadoc/org/apache/kafka/common/package-tree.html
index 13bc9d9..45a5155 100644
--- a/090/javadoc/org/apache/kafka/common/package-tree.html
+++ b/090/javadoc/org/apache/kafka/common/package-tree.html
@@ -2,9 +2,9 @@
<!-- NewPage -->
<html lang="en">
<head>
-<!-- Generated by javadoc (version 1.7.0_80) on Fri Nov 13 08:33:06 PST 2015 -->
+<!-- Generated by javadoc (version 1.7.0_80) on Tue Nov 17 18:38:11 PST 2015 -->
<title>org.apache.kafka.common Class Hierarchy (clients 0.9.0.0 API)</title>
-<meta name="date" content="2015-11-13">
+<meta name="date" content="2015-11-17">
<link rel="stylesheet" type="text/css" href="../../../../stylesheet.css" title="Style">
</head>
<body>
[3/3] kafka-site git commit: upload latest 0.9.0 docs
Posted by ju...@apache.org.
upload latest 0.9.0 docs
Project: http://git-wip-us.apache.org/repos/asf/kafka-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/kafka-site/commit/24d8d665
Tree: http://git-wip-us.apache.org/repos/asf/kafka-site/tree/24d8d665
Diff: http://git-wip-us.apache.org/repos/asf/kafka-site/diff/24d8d665
Branch: refs/heads/asf-site
Commit: 24d8d665e8ae4b986f5a976ec57fbe6c73ebec17
Parents: fdd6433
Author: Jun Rao <ju...@gmail.com>
Authored: Tue Nov 17 18:44:29 2015 -0800
Committer: Jun Rao <ju...@gmail.com>
Committed: Tue Nov 17 18:44:29 2015 -0800
----------------------------------------------------------------------
090/api.html | 8 +-
090/configuration.html | 14 +--
090/connect.html | 34 +++----
090/connect_config.html | 10 +-
090/consumer_config.html | 2 -
090/design.html | 72 +++++++--------
090/documentation.html | 16 ++--
090/ecosystem.html | 6 +-
090/implementation.html | 55 ++++++-----
090/introduction.html | 20 ++--
090/javadoc/allclasses-frame.html | 4 +-
090/javadoc/allclasses-noframe.html | 4 +-
090/javadoc/constant-values.html | 4 +-
090/javadoc/deprecated-list.html | 4 +-
090/javadoc/help-doc.html | 4 +-
090/javadoc/index-all.html | 4 +-
090/javadoc/index.html | 2 +-
.../clients/consumer/CommitFailedException.html | 4 +-
.../apache/kafka/clients/consumer/Consumer.html | 4 +-
.../kafka/clients/consumer/ConsumerConfig.html | 4 +-
.../consumer/ConsumerRebalanceListener.html | 4 +-
.../kafka/clients/consumer/ConsumerRecord.html | 4 +-
.../kafka/clients/consumer/ConsumerRecords.html | 4 +-
.../consumer/InvalidOffsetException.html | 4 +-
.../kafka/clients/consumer/KafkaConsumer.html | 4 +-
.../kafka/clients/consumer/MockConsumer.html | 4 +-
.../consumer/NoOffsetForPartitionException.html | 4 +-
.../clients/consumer/OffsetAndMetadata.html | 4 +-
.../clients/consumer/OffsetCommitCallback.html | 4 +-
.../consumer/OffsetOutOfRangeException.html | 4 +-
.../clients/consumer/OffsetResetStrategy.html | 4 +-
.../kafka/clients/consumer/RangeAssignor.html | 4 +-
.../clients/consumer/RoundRobinAssignor.html | 4 +-
.../kafka/clients/consumer/package-frame.html | 4 +-
.../kafka/clients/consumer/package-summary.html | 4 +-
.../kafka/clients/consumer/package-tree.html | 4 +-
.../producer/BufferExhaustedException.html | 4 +-
.../apache/kafka/clients/producer/Callback.html | 4 +-
.../kafka/clients/producer/KafkaProducer.html | 4 +-
.../kafka/clients/producer/MockProducer.html | 4 +-
.../kafka/clients/producer/Partitioner.html | 4 +-
.../apache/kafka/clients/producer/Producer.html | 4 +-
.../kafka/clients/producer/ProducerConfig.html | 4 +-
.../kafka/clients/producer/ProducerRecord.html | 4 +-
.../kafka/clients/producer/RecordMetadata.html | 4 +-
.../kafka/clients/producer/package-frame.html | 4 +-
.../kafka/clients/producer/package-summary.html | 4 +-
.../kafka/clients/producer/package-tree.html | 4 +-
.../org/apache/kafka/common/Cluster.html | 4 +-
.../org/apache/kafka/common/Configurable.html | 4 +-
.../org/apache/kafka/common/KafkaException.html | 4 +-
090/javadoc/org/apache/kafka/common/Metric.html | 4 +-
.../org/apache/kafka/common/MetricName.html | 4 +-
090/javadoc/org/apache/kafka/common/Node.html | 4 +-
.../org/apache/kafka/common/PartitionInfo.html | 4 +-
.../org/apache/kafka/common/TopicPartition.html | 4 +-
.../kafka/common/errors/ApiException.html | 4 +-
.../common/errors/AuthorizationException.html | 4 +-
.../errors/BrokerNotAvailableException.html | 4 +-
.../common/errors/ControllerMovedException.html | 4 +-
.../common/errors/CorruptRecordException.html | 4 +-
.../common/errors/DisconnectException.html | 4 +-
.../errors/GroupAuthorizationException.html | 4 +-
.../GroupCoordinatorNotAvailableException.html | 4 +-
.../errors/GroupLoadInProgressException.html | 4 +-
.../errors/IllegalGenerationException.html | 4 +-
.../kafka/common/errors/InterruptException.html | 4 +-
.../common/errors/InvalidMetadataException.html | 4 +-
.../errors/InvalidRequiredAcksException.html | 4 +-
.../common/errors/InvalidTopicException.html | 4 +-
.../errors/LeaderNotAvailableException.html | 4 +-
.../kafka/common/errors/NetworkException.html | 4 +-
.../errors/NotCoordinatorForGroupException.html | 4 +-
.../NotEnoughReplicasAfterAppendException.html | 4 +-
.../errors/NotEnoughReplicasException.html | 4 +-
.../errors/NotLeaderForPartitionException.html | 4 +-
.../common/errors/OffsetMetadataTooLarge.html | 4 +-
.../errors/RebalanceInProgressException.html | 4 +-
.../errors/RecordBatchTooLargeException.html | 4 +-
.../common/errors/RecordTooLargeException.html | 4 +-
.../kafka/common/errors/RetriableException.html | 4 +-
.../common/errors/SerializationException.html | 4 +-
.../kafka/common/errors/TimeoutException.html | 4 +-
.../errors/TopicAuthorizationException.html | 4 +-
.../common/errors/UnknownMemberIdException.html | 4 +-
.../common/errors/UnknownServerException.html | 4 +-
.../UnknownTopicOrPartitionException.html | 4 +-
.../kafka/common/errors/WakeupException.html | 4 +-
.../kafka/common/errors/package-frame.html | 4 +-
.../kafka/common/errors/package-summary.html | 4 +-
.../kafka/common/errors/package-tree.html | 4 +-
.../org/apache/kafka/common/package-frame.html | 4 +-
.../apache/kafka/common/package-summary.html | 4 +-
.../org/apache/kafka/common/package-tree.html | 4 +-
.../serialization/ByteArrayDeserializer.html | 4 +-
.../serialization/ByteArraySerializer.html | 4 +-
.../common/serialization/Deserializer.html | 4 +-
.../serialization/IntegerDeserializer.html | 4 +-
.../common/serialization/IntegerSerializer.html | 4 +-
.../common/serialization/LongDeserializer.html | 4 +-
.../common/serialization/LongSerializer.html | 4 +-
.../kafka/common/serialization/Serializer.html | 4 +-
.../serialization/StringDeserializer.html | 4 +-
.../common/serialization/StringSerializer.html | 4 +-
.../common/serialization/package-frame.html | 4 +-
.../common/serialization/package-summary.html | 4 +-
.../common/serialization/package-tree.html | 4 +-
090/javadoc/overview-frame.html | 4 +-
090/javadoc/overview-summary.html | 4 +-
090/javadoc/overview-tree.html | 4 +-
090/javadoc/serialized-form.html | 4 +-
090/kafka_config.html | 2 +-
090/migration.html | 8 +-
090/ops.html | 96 ++++++++++----------
090/producer_config.html | 2 -
090/quickstart.html | 34 +++----
090/security.html | 65 ++++++-------
090/upgrade.html | 12 +--
090/uses.html | 20 ++--
119 files changed, 436 insertions(+), 442 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/api.html
----------------------------------------------------------------------
diff --git a/090/api.html b/090/api.html
index 9b739da..8d79b20 100644
--- a/090/api.html
+++ b/090/api.html
@@ -17,7 +17,7 @@
Apache Kafka includes new java clients (in the org.apache.kafka.clients package). These are meant to supplant the older Scala clients, but for compatability they will co-exist for some time. These clients are available in a seperate jar with minimal dependencies, while the old Scala clients remain packaged with the server.
-<h3><a id="producerapi">2.1 Producer API</a></h3>
+<h3><a id="producerapi" href="#producerapi">2.1 Producer API</a></h3>
We encourage all new development to use the new Java producer. This client is production tested and generally both faster and more fully featured than the previous Scala client. You can use this client by adding a dependency on the client jar using the following example maven co-ordinates (you can change the version numbers with new releases):
<pre>
@@ -36,7 +36,7 @@ For those interested in the legacy Scala producer api, information can be found
here</a>.
</p>
-<h3><a id="highlevelconsumerapi">2.2 High Level Consumer API</a></h3>
+<h3><a id="highlevelconsumerapi" href="#highlevelconsumerapi">2.2 High Level Consumer API</a></h3>
<pre>
class Consumer {
/**
@@ -108,7 +108,7 @@ public interface kafka.javaapi.consumer.ConsumerConnector {
</pre>
You can follow
<a href="https://cwiki.apache.org/confluence/display/KAFKA/Consumer+Group+Example" title="Kafka 0.8 consumer example">this example</a> to learn how to use the high level consumer api.
-<h3><a id="simpleconsumerapi">2.3 Simple Consumer API</a></h3>
+<h3><a id="simpleconsumerapi" href="#simpleconsumerapi">2.3 Simple Consumer API</a></h3>
<pre>
class kafka.javaapi.consumer.SimpleConsumer {
/**
@@ -144,7 +144,7 @@ class kafka.javaapi.consumer.SimpleConsumer {
For most applications, the high level consumer Api is good enough. Some applications want features not exposed to the high level consumer yet (e.g., set initial offset when restarting the consumer). They can instead use our low level SimpleConsumer Api. The logic will be a bit more complicated and you can follow the example in
<a href="https://cwiki.apache.org/confluence/display/KAFKA/0.8.0+SimpleConsumer+Example" title="Kafka 0.8 SimpleConsumer example">here</a>.
-<h3><a id="newconsumerapi">2.4 New Consumer API</a></h3>
+<h3><a id="newconsumerapi" href="#newconsumerapi">2.4 New Consumer API</a></h3>
As of the 0.9.0 release we have added a replacement for our existing simple and high-level consumers. This client is considered beta quality. You can use this client by adding a dependency on the client jar using the following example maven co-ordinates (you can change the version numbers with new releases):
<pre>
<dependency>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/configuration.html
----------------------------------------------------------------------
diff --git a/090/configuration.html b/090/configuration.html
index abaff63..2dfc757 100644
--- a/090/configuration.html
+++ b/090/configuration.html
@@ -17,7 +17,7 @@
Kafka uses key-value pairs in the <a href="http://en.wikipedia.org/wiki/.properties">property file format</a> for configuration. These values can be supplied either from a file or programmatically.
-<h3><a id="brokerconfigs">3.1 Broker Configs</a></h3>
+<h3><a id="brokerconfigs" href="#brokerconfigs">3.1 Broker Configs</a></h3>
The essential configurations are the following:
<ul>
@@ -32,7 +32,7 @@ Topic-level configurations and defaults are discussed in more detail <a href="#t
<p>More details about broker configuration can be found in the scala class <code>kafka.server.KafkaConfig</code>.</p>
-<a id="topic-config">Topic-level configuration</a>
+<a id="topic-config" href="#topic-config">Topic-level configuration</a>
Configurations pertinent to topics have both a global default as well an optional per-topic override. If no per-topic configuration is given the global default is used. The override can be set at topic creation time by giving one or more <code>--config</code> options. This example creates a topic named <i>my-topic</i> with a custom max message size and flush rate:
<pre>
@@ -147,7 +147,7 @@ The following are the topic-level configurations. The server's default configura
</tr>
</table>
-<h3><a id="producerconfigs">3.2 Producer Configs</a></h3>
+<h3><a id="producerconfigs" href="#producerconfigs">3.2 Producer Configs</a></h3>
Below is the configuration of the Java producer:
<!--#include virtual="producer_config.html" -->
@@ -157,7 +157,7 @@ Below is the configuration of the Java producer:
here</a>.
</p>
-<h3><a id="consumerconfigs">3.3 Consumer Configs</a></h3>
+<h3><a id="consumerconfigs" href="#consumerconfigs">3.3 Consumer Configs</a></h3>
The essential consumer configurations are the following:
<ul>
<li><code>group.id</code>
@@ -327,9 +327,9 @@ The essential consumer configurations are the following:
<p>More details about consumer configuration can be found in the scala class <code>kafka.consumer.ConsumerConfig</code>.</p>
-<h3><a id="newconsumerconfigs">3.4 New Consumer Configs</a></h3>
+<h3><a id="newconsumerconfigs" href="#newconsumerconfigs">3.4 New Consumer Configs</a></h3>
Since 0.9.0.0 we have been working on a replacement for our existing simple and high-level consumers. The code can be considered beta quality. Below is the configuration for the new consumer:
<!--#include virtual="consumer_config.html" -->
-<h3><a id="connectconfigs">3.5 Kafka Connect Configs</a></h3>
-<!--#include virtual="connect_config.html" -->
\ No newline at end of file
+<h3><a id="connectconfigs" href="#connectconfigs">3.5 Kafka Connect Configs</a></h3>
+<!--#include virtual="connect_config.html" -->
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/connect.html
----------------------------------------------------------------------
diff --git a/090/connect.html b/090/connect.html
index 8791ab0..0a1a867 100644
--- a/090/connect.html
+++ b/090/connect.html
@@ -15,7 +15,7 @@
~ limitations under the License.
~-->
-<h3><a id="connect_overview">8.1 Overview</a></h3>
+<h3><a id="connect_overview" href="#connect_overview">8.1 Overview</a></h3>
Kafka Connect is a tool for scalably and reliably streaming data between Apache Kafka and other systems. It makes it simple to quickly define <i>connectors</i> that move large collections of data into and out of Kafka. Kafka Connect can ingest entire databases or collect metrics from all your application servers into Kafka topics, making the data available for stream processing with low latency. An export job can deliver data from Kafka topics into secondary storage and query systems or into batch systems for offline analysis.
@@ -29,11 +29,11 @@ Kafka Connect features include:
<li><b>Streaming/batch integration</b> - leveraging Kafka's existing capabilities, Kafka Connect is an ideal solution for bridging streaming and batch data systems</li>
</ul>
-<h3><a id="connect_user">8.2 User Guide</a></h3>
+<h3><a id="connect_user" href="#connect_user">8.2 User Guide</a></h3>
The quickstart provides a brief example of how to run a standalone version of Kafka Connect. This section describes how to configure, run, and manage Kafka Connect in more detail.
-<h4>Running Kafka Connect</h4>
+<h4><a id="connect_running" href="#connect_running">Running Kafka Connect</a></h4>
Kafka Connect currently supports two modes of execution: standalone (single process) and distributed.
@@ -64,7 +64,7 @@ The difference is in the class which is started and the configuration parameters
Note that in distributed mode the connector configurations are not passed on the command line. Instead, use the REST API described below to create, modify, and destroy connectors.
-<h4>Configuring Connectors</h4>
+<h4><a id="connect_configuring" href="#connect_configuring">Configuring Connectors</a></h4>
Connector configurations are simple key-value mappings. For standalone mode these are defined in a properties file and passed to the Connect process on the command line. In distributed mode, they will be included in the JSON payload for the request that creates (or modifies) the connector.
@@ -84,7 +84,7 @@ Sink connectors also have one additional option to control their input:
For any other options, you should consult the documentation for the connector.
-<h4>REST API</h4>
+<h4><a id="connect_rest" href="#connect_rest">REST API</a></h4>
Since Kafka Connect is intended to be run as a service, it also supports a REST API for managing connectors. By default this service runs on port 8083. The following are the currently supported endpoints:
@@ -98,13 +98,13 @@ Since Kafka Connect is intended to be run as a service, it also supports a REST
<li><code>DELETE /connectors/{name}</code> - delete a connector, halting all tasks and deleting its configuration</li>
</ul>
-<h3><a id="connect_development">8.3 Connector Development Guide</a></h3>
+<h3><a id="connect_development" href="#connect_development">8.3 Connector Development Guide</a></h3>
This guide describes how developers can write new connectors for Kafka Connect to move data between Kafka and other systems. It briefly reviews a few key concepts and then describes how to create a simple connector.
-<h4>Core Concepts and APIs</h4>
+<h4><a id="connect_concepts" href="#connect_concepts">Core Concepts and APIs</a></h4>
-<h5>Connectors and Tasks</h5>
+<h5><a id="connect_connectorsandtasks" href="#connect_connectorsandtasks">Connectors and Tasks</a></h5>
To copy data between Kafka and another system, users create a <code>Connector</code> for the system they want to pull data from or push data to. Connectors come in two flavors: <code>SourceConnectors</code> import data from another system (e.g. <code>JDBCSourceConnector</code> would import a relational database into Kafka) and <code>SinkConnectors</code> export data (e.g. <code>HDFSSinkConnector</code> would export the contents of a Kafka topic to an HDFS file).
@@ -113,24 +113,24 @@ To copy data between Kafka and another system, users create a <code>Connector</c
With an assignment in hand, each <code>Task</code> must copy its subset of the data to or from Kafka. In Kafka Connect, it should always be possible to frame these assignments as a set of input and output streams consisting of records with consistent schemas. Sometimes this mapping is obvious: each file in a set of log files can be considered a stream with each parsed line forming a record using the same schema and offsets stored as byte offsets in the file. In other cases it may require more effort to map to this model: a JDBC connector can map each table to a stream, but the offset is less clear. One possible mapping uses a timestamp column to generate queries incrementally returning new data, and the last queried timestamp can be used as the offset.
-<h5>Streams and Records</h5>
+<h5><a id="connect_streamsandrecords" href="#connect_streamsandrecords">Streams and Records</a></h5>
Each stream should be a sequence of key-value records. Both the keys and values can have complex structure -- many primitive types are provided, but arrays, objects, and nested data structures can be represented as well. The runtime data format does not assume any particular serialization format; this conversion is handled internally by the framework.
In addition to the key and value, records (both those generated by sources and those delivered to sinks) have associated stream IDs and offsets. These are used by the framework to periodically commit the offsets of data that have been processed so that in the event of failures, processing can resume from the last committed offsets, avoiding unnecessary reprocessing and duplication of events.
-<h5>Dynamic Connectors</h5>
+<h5><a id="connect_dynamicconnectors" href="#connect_dynamicconnectors">Dynamic Connectors</a></h5>
Not all jobs are static, so <code>Connector</code> implementations are also responsible for monitoring the external system for any changes that might require reconfiguration. For example, in the <code>JDBCSourceConnector</code> example, the <code>Connector</code> might assign a set of tables to each <code>Task</code>. When a new table is created, it must discover this so it can assign the new table to one of the <code>Tasks</code> by updating its configuration. When it notices a change that requires reconfiguration (or a change in the number of <code>Tasks</code>), it notifies the framework and the framework updates anycorresponding <code>Tasks</code>.
-<h4>Developing a Simple Connector</h4>
+<h4><a id="connect_developing" href="#connect_developing">Developing a Simple Connector</a></h4>
Developing a connector only requires implementing two interfaces, the <code>Connector</code> and <code>Task</code>. A simple example is included with the source code for Kafka in the <code>file</code> package. This connector is meant for use in standalone mode and has implementations of a <code>SourceConnector</code>/<code>SourceTask</code> to read each line of a file and emit it as a record and a <code>SinkConnector</code>/<code>SinkTask</code> that writes each record to a file.
The rest of this section will walk through some code to demonstrate the key steps in creating a connector, but developers should also refer to the full example source code as many details are omitted for brevity.
-<h5>Connector Example</h5>
+<h5><a id="connect_connectorexample" href="#connect_connectorexample">Connector Example</a></h5>
We'll cover the <code>SourceConnector</code> as a simple example. <code>SinkConnector</code> implementations are very similar. Start by creating the class that inherits from <code>SourceConnector</code> and add a couple of fields that will store parsed configuration information (the filename to read from and the topic to send data to):
@@ -187,7 +187,7 @@ Even with multiple tasks, this method implementation is usually pretty simple. I
Note that this simple example does not include dynamic input. See the discussion in the next section for how to trigger updates to task configs.
-<h5>Task Example - Source Task</h5>
+<h5><a id="connect_taskexample" href="#connect_taskexample">Task Example - Source Task</a></h5>
Next we'll describe the implementation of the corresponding <code>SourceTask</code>. The implementation is short, but too long to cover completely in this guide. We'll use pseudo-code to describe most of the implementation, but you can refer to the source code for the full example.
@@ -244,7 +244,7 @@ Again, we've omitted some details, but we can see the important steps: the <code
Note that this implementation uses the normal Java <code>InputStream</code>interface and may sleep if data is not avaiable. This is acceptable because Kafka Connect provides each task with a dedicated thread. While task implementations have to conform to the basic <code>poll()</code>interface, they have a lot of flexibility in how they are implemented. In this case, an NIO-based implementation would be more efficient, but this simple approach works, is quick to implement, and is compatible with older versions of Java.
-<h5>Sink Tasks</h5>
+<h5><a id="connect_sinktasks" href="#connect_sinktasks">Sink Tasks</a></h5>
The previous section described how to implement a simple <code>SourceTask</code>. Unlike <code>SourceConnector</code>and <code>SinkConnector</code>, <code>SourceTask</code>and <code>SinkTask</code>have very different interfaces because <code>SourceTask</code>uses a pull interface and <code>SinkTask</code>uses a push interface. Both share the common lifecycle methods, but the <code>SinkTask</code>interface is quite different:
@@ -263,7 +263,7 @@ The <code>flush()</code>method is used during the offset commit process, which a
delivery. For example, an HDFS connector could do this and use atomic move operations to make sure the <code>flush()</code>operation atomically commits the data and offsets to a final location in HDFS.
-<h5>Resuming from Previous Offsets</h5>
+<h5><a id="connect_resuming" href="#connect_resuming">Resuming from Previous Offsets</a></h5>
The <code>SourceTask</code>implementation included a stream ID (the input filename) and offset (position in the file) with each record. The framework uses this to commit offsets periodically so that in the case of a failure, the task can recover and minimize the number of events that are reprocessed and possibly duplicated (or to resume from the most recent offset if Kafka Connect was stopped gracefully, e.g. in standalone mode or due to a job reconfiguration). This commit process is completely automated by the framework, but only the connector knows how to seek back to the right position in the input stream to resume from that location.
@@ -281,7 +281,7 @@ To correctly resume upon startup, the task can use the <code>SourceContext</code
Of course, you might need to read many keys for each of the input streams. The <code>OffsetStorageReader</code> interface also allows you to issue bulk reads to efficiently load all offsets, then apply them by seeking each input stream to the appropriate position.
-<h4>Dynamic Input/Output Streams</h4>
+<h4><a id="connect_dynamicio" href="#connect_dynamicio">Dynamic Input/Output Streams</a></h4>
Kafka Connect is intended to define bulk data copying jobs, such as copying an entire database rather than creating many jobs to copy each table individually. One consequence of this design is that the set of input or output streams for a connector can vary over time.
@@ -299,7 +299,7 @@ Ideally this code for monitoring changes would be isolated to the <code>Connecto
<code>SinkConnectors</code> usually only have to handle the addition of streams, which may translate to new entries in their outputs (e.g., a new database table). The framework manages any changes to the Kafka input, such as when the set of input topics changes because of a regex subscription. <code>SinkTasks</code>should expect new input streams, which may require creating new resources in the downstream system, such as a new table in a database. The trickiest situation to handle in these cases may be conflicts between multiple <code>SinkTasks</code>seeing a new input stream for the first time and simultaneoulsy trying to create the new resource. <code>SinkConnectors</code>, on the other hand, will generally require no special code for handling a dynamic set of streams.
-<h4>Working with Schemas</h4>
+<h4><a id="connect_schemas" href="#connect_schemas">Working with Schemas</a></h4>
The FileStream connectors are good examples because they are simple, but they also have trivially structured data -- each line is just a string. Almost all practical connectors will need schemas with more complex data formats.
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/connect_config.html
----------------------------------------------------------------------
diff --git a/090/connect_config.html b/090/connect_config.html
index d854943..ef051b9 100644
--- a/090/connect_config.html
+++ b/090/connect_config.html
@@ -26,15 +26,15 @@
<tr>
<td>session.timeout.ms</td><td>The timeout used to detect failures when using Kafka's group management facilities.</td><td>int</td><td>30000</td><td></td><td>high</td></tr>
<tr>
-<td>ssl.key.password</td><td>The password of the private key in the key store file. This is optional for client.</td><td>string</td><td>null</td><td></td><td>high</td></tr>
+<td>ssl.key.password</td><td>The password of the private key in the key store file. This is optional for client.</td><td>password</td><td>null</td><td></td><td>high</td></tr>
<tr>
<td>ssl.keystore.location</td><td>The location of the key store file. This is optional for client and can be used for two-way authentication for client.</td><td>string</td><td>null</td><td></td><td>high</td></tr>
<tr>
-<td>ssl.keystore.password</td><td>The store password for the key store file.This is optional for client and only needed if ssl.keystore.location is configured. </td><td>string</td><td>null</td><td></td><td>high</td></tr>
+<td>ssl.keystore.password</td><td>The store password for the key store file.This is optional for client and only needed if ssl.keystore.location is configured. </td><td>password</td><td>null</td><td></td><td>high</td></tr>
<tr>
<td>ssl.truststore.location</td><td>The location of the trust store file. </td><td>string</td><td>null</td><td></td><td>high</td></tr>
<tr>
-<td>ssl.truststore.password</td><td>The password for the trust store file. </td><td>string</td><td>null</td><td></td><td>high</td></tr>
+<td>ssl.truststore.password</td><td>The password for the trust store file. </td><td>password</td><td>null</td><td></td><td>high</td></tr>
<tr>
<td>connections.max.idle.ms</td><td>Close idle connections after the number of milliseconds specified by this config.</td><td>long</td><td>540000</td><td></td><td>medium</td></tr>
<tr>
@@ -42,8 +42,6 @@
<tr>
<td>request.timeout.ms</td><td>The configuration controls the maximum amount of time the client will wait for the response of a request. If the response is not received before the timeout elapses the client will resend the request if necessary or fail the request if retries are exhausted.</td><td>int</td><td>40000</td><td>[0,...]</td><td>medium</td></tr>
<tr>
-<td>sasl.kerberos.principal.to.local.rules</td><td>A list of rules for mapping from principal names to short names (typically operating system usernames). The rules are evaluated in order and the first rule that matches a principal name is used to map it to a short name. Any later rules in the list are ignored. By default, principal names of the form <username>/<hostname>@<REALM> are mapped to <username>.</td><td>list</td><td>[DEFAULT]</td><td></td><td>medium</td></tr>
-<tr>
<td>sasl.kerberos.service.name</td><td>The Kerberos principal name that Kafka runs as. This can be defined either in Kafka's JAAS config or in Kafka's config.</td><td>string</td><td>null</td><td></td><td>medium</td></tr>
<tr>
<td>security.protocol</td><td>Protocol used to communicate with brokers. Currently only PLAINTEXT and SSL are supported.</td><td>string</td><td>PLAINTEXT</td><td></td><td>medium</td></tr>
@@ -78,8 +76,6 @@
<tr>
<td>offset.flush.timeout.ms</td><td>Maximum number of milliseconds to wait for records to flush and partition offset data to be committed to offset storage before cancelling the process and restoring the offset data to be committed in a future attempt.</td><td>long</td><td>5000</td><td></td><td>low</td></tr>
<tr>
-<td>principal.builder.class</td><td>principal builder to generate a java Principal. This config is optional for client.</td><td>class</td><td>class org.apache.kafka.common.security.auth.DefaultPrincipalBuilder</td><td></td><td>low</td></tr>
-<tr>
<td>reconnect.backoff.ms</td><td>The amount of time to wait before attempting to reconnect to a given host. This avoids repeatedly connecting to a host in a tight loop. This backoff applies to all requests sent by the consumer to the broker.</td><td>long</td><td>50</td><td>[0,...]</td><td>low</td></tr>
<tr>
<td>rest.advertised.host.name</td><td>If this is set, this is the hostname that will be given out to other workers to connect to.</td><td>string</td><td>null</td><td></td><td>low</td></tr>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/consumer_config.html
----------------------------------------------------------------------
diff --git a/090/consumer_config.html b/090/consumer_config.html
index fb97e54..c894e71 100644
--- a/090/consumer_config.html
+++ b/090/consumer_config.html
@@ -78,8 +78,6 @@
<tr>
<td>metrics.sample.window.ms</td><td>The number of samples maintained to compute metrics.</td><td>long</td><td>30000</td><td>[0,...]</td><td>low</td></tr>
<tr>
-<td>principal.builder.class</td><td>principal builder to generate a java Principal. This config is optional for client.</td><td>class</td><td>class org.apache.kafka.common.security.auth.DefaultPrincipalBuilder</td><td></td><td>low</td></tr>
-<tr>
<td>reconnect.backoff.ms</td><td>The amount of time to wait before attempting to reconnect to a given host. This avoids repeatedly connecting to a host in a tight loop. This backoff applies to all requests sent by the consumer to the broker.</td><td>long</td><td>50</td><td>[0,...]</td><td>low</td></tr>
<tr>
<td>retry.backoff.ms</td><td>The amount of time to wait before attempting to retry a failed fetch request to a given topic partition. This avoids repeated fetching-and-failing in a tight loop.</td><td>long</td><td>100</td><td>[0,...]</td><td>low</td></tr>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/design.html
----------------------------------------------------------------------
diff --git a/090/design.html b/090/design.html
index 347f602..5d3090c 100644
--- a/090/design.html
+++ b/090/design.html
@@ -5,9 +5,9 @@
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
-
+
http://www.apache.org/licenses/LICENSE-2.0
-
+
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -15,7 +15,7 @@
limitations under the License.
-->
-<h3><a id="majordesignelements">4.1 Motivation</a></h3>
+<h3><a id="majordesignelements" href="#majordesignelements">4.1 Motivation</a></h3>
<p>
We designed Kafka to be able to act as a unified platform for handling all the real-time data feeds <a href="#introduction">a large company might have</a>. To do this we had to think through a fairly broad set of use cases.
<p>
@@ -31,8 +31,8 @@ Finally in cases where the stream is fed into other data systems for serving we
<p>
Supporting these uses led use to a design with a number of unique elements, more akin to a database log then a traditional messaging system. We will outline some elements of the design in the following sections.
-<h3><a id="persistence">4.2 Persistence</a></h3>
-<h4>Don't fear the filesystem!</h4>
+<h3><a id="persistence" href="#persistence">4.2 Persistence</a></h3>
+<h4><a id="design_filesystem" href="#design_filesystem">Don't fear the filesystem!</a></h4>
<p>
Kafka relies heavily on the filesystem for storing and caching messages. There is a general perception that "disks are slow" which makes people skeptical that a persistent structure can offer competitive performance. In fact disks are both much slower and much faster than people expect depending on how they are used; and a properly designed disk structure can often be as fast as the network.
<p>
@@ -52,7 +52,7 @@ This suggests a design which is very simple: rather than maintain as much as pos
<p>
This style of pagecache-centric design is described in an <a href="http://varnish.projects.linpro.no/wiki/ArchitectNotes">article</a> on the design of Varnish here (along with a healthy dose of arrogance).
-<h4>Constant Time Suffices</h4>
+<h4><a id="design_constanttime" href="#design_constanttime">Constant Time Suffices</a></h4>
<p>
The persistent data structure used in messaging systems are often a per-consumer queue with an associated BTree or other general-purpose random access data structures to maintain metadata about messages. BTrees are the most versatile data structure available, and make it possible to support a wide variety of transactional and non-transactional semantics in the messaging system. They do come with a fairly high cost, though: Btree operations are O(log N). Normally O(log N) is considered essentially equivalent to constant time, but this is not true for disk operations. Disk seeks come at 10 ms a pop, and each disk can do only one seek at a time so parallelism is limited. Hence even a handful of disk seeks leads to very high overhead. Since storage systems mix very fast cached operations with very slow physical disk operations, the observed performance of tree structures is often superlinear as data increases with fixed cache--i.e. doubling your data makes things much worse then twice a
s slow.
<p>
@@ -60,7 +60,7 @@ Intuitively a persistent queue could be built on simple reads and appends to fil
<p>
Having access to virtually unlimited disk space without any performance penalty means that we can provide some features not usually found in a messaging system. For example, in Kafka, instead of attempting to deleting messages as soon as they are consumed, we can retain messages for a relative long period (say a week). This leads to a great deal of flexibility for consumers, as we will describe.
-<h3><a id="maximizingefficiency">4.3 Efficiency</a></h3>
+<h3><a id="maximizingefficiency" href="#maximizingefficiency">4.3 Efficiency</a></h3>
<p>
We have put significant effort into efficiency. One of our primary use cases is handling web activity data, which is very high volume: each page view may generate dozens of writes. Furthermore we assume each message published is read by at least one consumer (often many), hence we strive to make consumption as cheap as possible.
<p>
@@ -74,7 +74,7 @@ To avoid this, our protocol is built around a "message set" abstraction that nat
<p>
This simple optimization produces orders of magnitude speed up. Batching leads to larger network packets, larger sequential disk operations, contiguous memory blocks, and so on, all of which allows Kafka to turn a bursty stream of random message writes into linear writes that flow to the consumers.
<p>
-The other inefficiency is in byte copying. At low message rates this is not an issue, but under load the impact is significant. To avoid this we employ a standardized binary message format that is shared by the producer, the broker, and the consumer (so data chunks can be transferred without modification between them).
+The other inefficiency is in byte copying. At low message rates this is not an issue, but under load the impact is significant. To avoid this we employ a standardized binary message format that is shared by the producer, the broker, and the consumer (so data chunks can be transferred without modification between them).
<p>
The message log maintained by the broker is itself just a directory of files, each populated by a sequence of message sets that have been written to disk in the same format used by the producer and consumer. Maintaining this common format allows optimization of the most important operation: network transfer of persistent log chunks. Modern unix operating systems offer a highly optimized code path for transferring data out of pagecache to a socket; in Linux this is done with the <a href="http://man7.org/linux/man-pages/man2/sendfile.2.html">sendfile system call</a>.
<p>
@@ -94,7 +94,7 @@ This combination of pagecache and sendfile means that on a Kafka cluster where t
<p>
For more background on the sendfile and zero-copy support in Java, see this <a href="http://www.ibm.com/developerworks/linux/library/j-zerocopy">article</a>.
-<h4>End-to-end Batch Compression</h4>
+<h4><a id="design_compression" href="#design_compression">End-to-end Batch Compression</a></h4>
<p>
In some cases the bottleneck is actually not CPU or disk but network bandwidth. This is particularly true for a data pipeline that needs to send messages between data centers over a wide-area network. Of course the user can always compress its messages one at a time without any support needed from Kafka, but this can lead to very poor compression ratios as much of the redundancy is due to repetition between messages of the same type (e.g. field names in JSON or user agents in web logs or common string values). Efficient compression requires compressing multiple messages together rather than compressing each message individually.
<p>
@@ -102,25 +102,25 @@ Kafka supports this by allowing recursive message sets. A batch of messages can
<p>
Kafka supports GZIP and Snappy compression protocols. More details on compression can be found <a href="https://cwiki.apache.org/confluence/display/KAFKA/Compression">here</a>.
-<h3><a id="theproducer">4.4 The Producer</a></h3>
+<h3><a id="theproducer" href="#theproducer">4.4 The Producer</a></h3>
-<h4>Load balancing</h4>
+<h4><a id="design_loadbalancing" href="#design_loadbalancing">Load balancing</a></h4>
<p>
The producer sends data directly to the broker that is the leader for the partition without any intervening routing tier. To help the producer do this all Kafka nodes can answer a request for metadata about which servers are alive and where the leaders for the partitions of a topic are at any given time to allow the producer to appropriate direct its requests.
<p>
The client controls which partition it publishes messages to. This can be done at random, implementing a kind of random load balancing, or it can be done by some semantic partitioning function. We expose the interface for semantic partitioning by allowing the user to specify a key to partition by and using this to hash to a partition (there is also an option to override the partition function if need be). For example if the key chosen was a user id then all data for a given user would be sent to the same partition. This in turn will allow consumers to make locality assumptions about their consumption. This style of partitioning is explicitly designed to allow locality-sensitive processing in consumers.
-<h4>Asynchronous send</h4>
+<h4><a id="design_asyncsend" href="#design_asyncsend">Asynchronous send</a></h4>
<p>
Batching is one of the big drivers of efficiency, and to enable batching the Kafka producer will attempt to accumulate data in memory and to send out larger batches in a single request. The batching can be configured to accumulate no more than a fixed number of messages and to wait no longer than some fixed latency bound (say 64k or 10 ms). This allows the accumulation of more bytes to send, and few larger I/O operations on the servers. This buffering is configurable and gives a mechanism to trade off a small amount of additional latency for better throughput.
<p>
Details on <a href="#newproducerconfigs">configuration</a> and <a href="http://kafka.apache.org/082/javadoc/index.html?org/apache/kafka/clients/producer/KafkaProducer.html">api</a> for the producer can be found elsewhere in the documentation.
-<h3><a id="theconsumer">4.5 The Consumer</a></h3>
+<h3><a id="theconsumer" href="#theconsumer">4.5 The Consumer</a></h3>
The Kafka consumer works by issuing "fetch" requests to the brokers leading the partitions it wants to consume. The consumer specifies its offset in the log with each request and receives back a chunk of log beginning from that position. The consumer thus has significant control over this position and can rewind it to re-consume data if need be.
-<h4>Push vs. pull</h4>
+<h4><a id="design_pull" href="#design_pull">Push vs. pull</a></h4>
<p>
An initial question we considered is whether consumers should pull data from brokers or brokers should push data to the consumer. In this respect Kafka follows a more traditional design, shared by most messaging systems, where data is pushed to the broker from the producer and pulled from the broker by the consumer. Some logging-centric systems, such as <a href="http://github.com/facebook/scribe">Scribe</a> and <a href="http://flume.apache.org/">Apache Flume</a> follow a very different push based path where data is pushed downstream. There are pros and cons to both approaches. However a push-based system has difficulty dealing with diverse consumers as the broker controls the rate at which data is transferred. The goal is generally for the consumer to be able to consume at the maximum possible rate; unfortunately in a push system this means the consumer tends to be overwhelmed when its rate of consumption falls below the rate of production (a denial of service attack, in essence).
A pull-based system has the nicer property that the consumer simply falls behind and catches up when it can. This can be mitigated with some kind of backoff protocol by which the consumer can indicate it is overwhelmed, but getting the rate of transfer to fully utilize (but never over-utilize) the consumer is trickier than it seems. Previous attempts at building systems in this fashion led us to go with a more traditional pull model.
<p>
@@ -130,7 +130,7 @@ The deficiency of a naive pull-based system is that if the broker has no data th
<p>
You could imagine other possible designs which would be only pull, end-to-end. The producer would locally write to a local log, and brokers would pull from that with consumers pulling from them. A similar type of "store-and-forward" producer is often proposed. This is intriguing but we felt not very suitable for our target use cases which have thousands of producers. Our experience running persistent data systems at scale led us to feel that involving thousands of disks in the system across many applications would not actually make things more reliable and would be a nightmare to operate. And in practice we have found that we can run a pipeline with strong SLAs at large scale without a need for producer persistence.
-<h4>Consumer Position</h4>
+<h4><a id="design_consumerposition" href="#design_consumerposition">Consumer Position</a></h4>
Keeping track of <i>what</i> has been consumed, is, surprisingly, one of the key performance points of a messaging system.
<p>
Most messaging systems keep metadata about what messages have been consumed on the broker. That is, as a message is handed out to a consumer, the broker either records that fact locally immediately or it may wait for acknowledgement from the consumer. This is a fairly intuitive choice, and indeed for a single machine server it is not clear where else this state could go. Since the data structure used for storage in many messaging systems scale poorly, this is also a pragmatic choice--since the broker knows what is consumed it can immediately delete it, keeping the data size small.
@@ -141,13 +141,13 @@ Kafka handles this differently. Our topic is divided into a set of totally order
<p>
There is a side benefit of this decision. A consumer can deliberately <i>rewind</i> back to an old offset and re-consume data. This violates the common contract of a queue, but turns out to be an essential feature for many consumers. For example, if the consumer code has a bug and is discovered after some messages are consumed, the consumer can re-consume those messages once the bug is fixed.
-<h4>Offline Data Load</h4>
+<h4><a id="design_offlineload" href="#design_offlineload">Offline Data Load</a></h4>
Scalable persistence allows for the possibility of consumers that only periodically consume such as batch data loads that periodically bulk-load data into an offline system such as Hadoop or a relational data warehouse.
<p>
In the case of Hadoop we parallelize the data load by splitting the load over individual map tasks, one for each node/topic/partition combination, allowing full parallelism in the loading. Hadoop provides the task management, and tasks which fail can restart without danger of duplicate data—they simply restart from their original position.
-<h3><a id="semantics">4.6 Message Delivery Semantics</a></h3>
+<h3><a id="semantics" href="#semantics">4.6 Message Delivery Semantics</a></h3>
<p>
Now that we understand a little about how producers and consumers work, let's discuss the semantic guarantees Kafka provides between producer and consumer. Clearly there are multiple possible message delivery guarantees that could be provided:
<ul>
@@ -160,7 +160,7 @@ Now that we understand a little about how producers and consumers work, let's di
<li>
<i>Exactly once</i>—this is what people actually want, each message is delivered once and only once.
</li>
-</ul>
+</ul>
It's worth noting that this breaks down into two problems: the durability guarantees for publishing a message and the guarantees when consuming a message.
<p>
@@ -181,7 +181,7 @@ Now let's describe the semantics from the point-of-view of the consumer. All rep
<p>
So effectively Kafka guarantees at-least-once delivery by default and allows the user to implement at most once delivery by disabling retries on the producer and committing its offset prior to processing a batch of messages. Exactly-once delivery requires co-operation with the destination storage system but Kafka provides the offset which makes implementing this straight-forward.
-<h3><a id="replication">4.7 Replication</a></h3>
+<h3><a id="replication" href="#replication">4.7 Replication</a></h3>
<p>
Kafka replicates the log for each topic's partitions across a configurable number of servers (you can set this replication factor on a topic-by-topic basis). This allows automatic failover to these replicas when a server in the cluster fails so messages remain available in the presence of failures.
<p>
@@ -206,7 +206,7 @@ The guarantee that Kafka offers is that a committed message will not be lost, as
<p>
Kafka will remain available in the presence of node failures after a short fail-over period, but may not remain available in the presence of network partitions.
-<h4>Replicated Logs: Quorums, ISRs, and State Machines (Oh my!)</h4>
+<h4><a id="design_replicatedlog" href="#design_replicatedlog">Replicated Logs: Quorums, ISRs, and State Machines (Oh my!)</a></h4>
At its heart a Kafka partition is a replicated log. The replicated log is one of the most basic primitives in distributed data systems, and there are many approaches for implementing one. A replicated log can be used by other systems as a primitive for implementing other distributed systems in the <a href="http://en.wikipedia.org/wiki/State_machine_replication">state-machine style</a>.
<p>
@@ -230,7 +230,7 @@ For most use cases we hope to handle, we think this tradeoff is a reasonable one
<p>
Another important design distinction is that Kafka does not require that crashed nodes recover with all their data intact. It is not uncommon for replication algorithms in this space to depend on the existence of "stable storage" that cannot be lost in any failure-recovery scenario without potential consistency violations. There are two primary problems with this assumption. First, disk errors are the most common problem we observe in real operation of persistent data systems and they often do not leave data intact. Secondly, even if this were not a problem, we do not want to require the use of fsync on every write for our consistency guarantees as this can reduce performance by two to three orders of magnitude. Our protocol for allowing a replica to rejoin the ISR ensures that before rejoining, it must fully re-sync again even if it lost unflushed data in its crash.
-<h4>Unclean leader election: What if they all die?</h4>
+<h4><a id="design_uncleanleader" href="#design_uncleanleader">Unclean leader election: What if they all die?</a></h4>
Note that Kafka's guarantee with respect to data loss is predicated on at least on replica remaining in sync. If all the nodes replicating a partition die, this guarantee no longer holds.
<p>
@@ -245,10 +245,10 @@ This is a simple tradeoff between availability and consistency. If we wait for r
This dilemma is not specific to Kafka. It exists in any quorum-based scheme. For example in a majority voting scheme, if a majority of servers suffer a permanent failure, then you must either choose to lose 100% of your data or violate consistency by taking what remains on an existing server as your new source of truth.
-<h4>Availability and Durability Guarantees</h4>
+<h4><a id="design_ha" href="#design_ha">Availability and Durability Guarantees</a></h4>
When writing to Kafka, producers can choose whether they wait for the message to be acknowledged by 0,1 or all (-1) replicas.
-Note that "acknowledgement by all replicas" does not guarantee that the full set of assigned replicas have received the message. By default, when request.required.acks=-1, acknowledgement happens as soon as all the current in-sync replicas have received the message. For example, if a topic is configured with only two replicas and one fails (i.e., only one in sync replica remains), then writes that specify request.required.acks=-1 will succeed. However, these writes could be lost if the remaining replica also fails.
+Note that "acknowledgement by all replicas" does not guarantee that the full set of assigned replicas have received the message. By default, when request.required.acks=-1, acknowledgement happens as soon as all the current in-sync replicas have received the message. For example, if a topic is configured with only two replicas and one fails (i.e., only one in sync replica remains), then writes that specify request.required.acks=-1 will succeed. However, these writes could be lost if the remaining replica also fails.
Although this ensures maximum availability of the partition, this behavior may be undesirable to some users who prefer durability over availability. Therefore, we provide two topic-level configurations that can be used to prefer message durability over availability:
<ol>
@@ -258,13 +258,13 @@ This setting offers a trade-off between consistency and availability. A higher s
</ol>
-<h4>Replica Management</h4>
+<h4><a id="design_replicamanagment" href="#design_replicamanagment">Replica Management</a></h4>
The above discussion on replicated logs really covers only a single log, i.e. one topic partition. However a Kafka cluster will manage hundreds or thousands of these partitions. We attempt to balance partitions within a cluster in a round-robin fashion to avoid clustering all partitions for high-volume topics on a small number of nodes. Likewise we try to balance leadership so that each node is the leader for a proportional share of its partitions.
<p>
It is also important to optimize the leadership election process as that is the critical window of unavailability. A naive implementation of leader election would end up running an election per partition for all partitions a node hosted when that node failed. Instead, we elect one of the brokers as the "controller". This controller detects failures at the broker level and is responsible for changing the leader of all affected partitions in a failed broker. The result is that we are able to batch together many of the required leadership change notifications which makes the election process far cheaper and faster for a large number of partitions. If the controller fails, one of the surviving brokers will become the new controller.
-<h3><a id="compaction">4.8 Log Compaction</a></h3>
+<h3><a id="compaction" href="#compaction">4.8 Log Compaction</a></h3>
Log compaction ensures that Kafka will always retain at least the last known value for each message key within the log of data for a single topic partition. It addresses use cases and scenarios such as restoring state after application crashes or system failure, or reloading caches after application restarts during operational maintenance. Let's dive into these use cases in more detail and then describe how compaction works.
<p>
@@ -299,10 +299,10 @@ The general idea is quite simple. If we had infinite log retention, and we logge
Log compaction is a mechanism to give finer-grained per-record retention, rather than the coarser-grained time-based retention. The idea is to selectively remove records where we have a more recent update with the same primary key. This way the log is guaranteed to have at least the last state for each key.
<p>
This retention policy can be set per-topic, so a single cluster can have some topics where retention is enforced by size or time and other topics where retention is enforced by compaction.
-<p>
+<p>
This functionality is inspired by one of LinkedIn's oldest and most successful pieces of infrastructure—a database changelog caching service called <a href="https://github.com/linkedin/databus">Databus</a>. Unlike most log-structured storage systems Kafka is built for subscription and organizes data for fast linear reads and writes. Unlike Databus, Kafka acts a source-of-truth store so it is useful even in situations where the upstream data source would not otherwise be replayable.
-<h4>Log Compaction Basics</h4>
+<h4><a id="design_compactionbasics" href="#design_compactionbasics">Log Compaction Basics</a></h4>
Here is a high-level picture that shows the logical structure of a Kafka log with the offset for each message.
<p>
@@ -316,7 +316,7 @@ The compaction is done in the background by periodically recopying log segments.
<p>
<img src="images/log_compaction.png">
<p>
-<h4>What guarantees does log compaction provide?</h4>
+<h4><a id="design_compactionguarantees" href="#design_compactionguarantees">What guarantees does log compaction provide?</a></h4>
Log compaction guarantees the following:
<ol>
@@ -327,7 +327,7 @@ Log compaction guarantees the following:
<li>Any consumer progressing from the start of the log, will see at least the <em>final</em> state of all records in the order they were written. All delete markers for deleted records will be seen provided the consumer reaches the head of the log in a time period less than the topic's <code>delete.retention.ms</code> setting (the default is 24 hours). This is important as delete marker removal happens concurrently with read, and thus it is important that we do not remove any delete marker prior to the consumer seeing it.
</ol>
-<h4>Log Compaction Details</h4>
+<h4><a id="design_compactiondetails" href="#design_compactiondetails">Log Compaction Details</a></h4>
Log compaction is handled by the log cleaner, a pool of background threads that recopy log segment files, removing records whose key appears in the head of the log. Each compactor thread works as follows:
<ol>
@@ -337,7 +337,7 @@ Log compaction is handled by the log cleaner, a pool of background threads that
<li>The summary of the log head is essentially just a space-compact hash table. It uses exactly 24 bytes per entry. As a result with 8GB of cleaner buffer one cleaner iteration can clean around 366GB of log head (assuming 1k messages).
</ol>
<p>
-<h4>Configuring The Log Cleaner</h4>
+<h4><a id="design_compactionconfig" href="#design_compactionconfig">Configuring The Log Cleaner</a></h4>
The log cleaner is disabled by default. To enable it set the server config
<pre> log.cleaner.enable=true</pre>
@@ -347,21 +347,21 @@ This can be done either at topic creation time or using the alter topic command.
<p>
Further cleaner configurations are described <a href="/documentation.html#brokerconfigs">here</a>.
-<h4>Log Compaction Limitations</h4>
+<h4><a id="design_compactionlimitations" href="#design_compactionlimitations">Log Compaction Limitations</a></h4>
<ol>
<li>You cannot configure yet how much log is retained without compaction (the "head" of the log). Currently all segments are eligible except for the last segment, i.e. the one currently being written to.</li>
<li>Log compaction is not yet compatible with compressed topics.</li>
</ol>
-<h3><a id="semantics">4.9 Quotas</a></h3>
+<h3><a id="design_quotas" href="#design_quotas">4.9 Quotas</a></h3>
<p>
Starting in 0.9, the Kafka cluster has the ability to enforce quotas on produce and fetch requests. Quotas are basically byte-rate thresholds defined per client-id. A client-id logically identifies an application making a request. Hence a single client-id can span multiple producer and consumer instances and the quota will apply for all of them as a single entity i.e. if client-id="test-client" has a produce quota of 10MB/sec, this is shared across all instances with that same id.
-<h4>Why are quotas necessary?</h4>
+<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.
</p>
-<h4>Enforcement</h4>
+<h4><a id="design_quotasenforcement" href="#design_quotasenforcement">Enforcement</a></h4>
<p>
By default, each unique client-id receives a fixed quota in bytes/sec as configured by the cluster (quota.producer.default, quota.consumer.default).
This quota is defined on a per-broker basis. Each client can publish/fetch a maximum of X bytes/sec per broker before it gets throttled. We decided that defining these quotas per broker is much better than having a fixed cluster wide bandwidth per client because that would require a mechanism to share client quota usage among all the brokers. This can be harder to get right than the quota implementation itself!
@@ -372,9 +372,9 @@ It is possible for producers and consumers to produce/consume very high volumes
<p>
Client byte rate is measured over multiple small windows (for e.g. 30 windows of 1 second each) in order to detect and correct quota violations quickly. Typically, having large measurement windows (for e.g. 10 windows of 30 seconds each) leads to large bursts of traffic followed by long delays which is not great in terms of user experience.
</p>
-<h4>Quota overrides</h4>
+<h4><a id="design_quotasoverrides" href="#design_quotasoverrides">Quota overrides</a></h4>
<p>
It is possible to override the default quota for client-ids that need a higher (or even lower) quota. The mechanism is similar to the per-topic log config overrides.
Client-id overrides are written to ZooKeeper under <i><b>/config/clients</b></i>. These overrides are read by all brokers and are effective immediately. This lets us change quotas without having to do a rolling restart of the entire cluster. See <a href="/ops.html#quotas">here</a> for details.
-</p>
\ No newline at end of file
+</p>
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/documentation.html
----------------------------------------------------------------------
diff --git a/090/documentation.html b/090/documentation.html
index eddc0c6..53c801e 100644
--- a/090/documentation.html
+++ b/090/documentation.html
@@ -131,37 +131,37 @@ Prior releases: <a href="/07/documentation.html">0.7.x</a>, <a href="/08/documen
</li>
</ul>
-<h2><a id="gettingStarted">1. Getting Started</a></h2>
+<h2><a id="gettingStarted" href="#gettingStarted">1. Getting Started</a></h2>
<!--#include virtual="introduction.html" -->
<!--#include virtual="uses.html" -->
<!--#include virtual="quickstart.html" -->
<!--#include virtual="ecosystem.html" -->
<!--#include virtual="upgrade.html" -->
-<h2><a id="api">2. API</a></h2>
+<h2><a id="api" href="#api">2. API</a></h2>
<!--#include virtual="api.html" -->
-<h2><a id="configuration">3. Configuration</a></h2>
+<h2><a id="configuration" href="#configuration">3. Configuration</a></h2>
<!--#include virtual="configuration.html" -->
-<h2><a id="design">4. Design</a></h2>
+<h2><a id="design" href="#design">4. Design</a></h2>
<!--#include virtual="design.html" -->
-<h2><a id="implementation">5. Implementation</a></h2>
+<h2><a id="implementation" href="#implementation">5. Implementation</a></h2>
<!--#include virtual="implementation.html" -->
-<h2><a id="operations">6. Operations</a></h2>
+<h2><a id="operations" href="#operations">6. Operations</a></h2>
<!--#include virtual="ops.html" -->
-<h2><a id="security">7. Security</a></h2>
+<h2><a id="security" href="#security">7. Security</a></h2>
<!--#include virtual="security.html" -->
-<h2><a id="connect">8. Kafka Connect</a></h2>
+<h2><a id="connect" href="#connect">8. Kafka Connect</a></h2>
<!--#include virtual="connect.html" -->
<!--#include virtual="../includes/footer.html" -->
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/ecosystem.html
----------------------------------------------------------------------
diff --git a/090/ecosystem.html b/090/ecosystem.html
index e99a446..73d5706 100644
--- a/090/ecosystem.html
+++ b/090/ecosystem.html
@@ -5,9 +5,9 @@
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
-
+
http://www.apache.org/licenses/LICENSE-2.0
-
+
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -15,6 +15,6 @@
limitations under the License.
-->
-<h3><a id="ecosystem">1.4 Ecosystem</a></h3>
+<h3><a id="ecosystem" href="#ecosystem">1.4 Ecosystem</a></h3>
There are a plethora of tools that integrate with Kafka outside the main distribution. The <a href="https://cwiki.apache.org/confluence/display/KAFKA/Ecosystem"> ecosystem page</a> lists many of these, including stream processing systems, Hadoop integration, monitoring, and deployment tools.
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/24d8d665/090/implementation.html
----------------------------------------------------------------------
diff --git a/090/implementation.html b/090/implementation.html
index b95d36f..0b603d4 100644
--- a/090/implementation.html
+++ b/090/implementation.html
@@ -15,9 +15,9 @@
limitations under the License.
-->
-<h3><a id="apidesign">5.1 API Design</a></h3>
+<h3><a id="apidesign" href="#apidesign">5.1 API Design</a></h3>
-<h4>Producer APIs</h4>
+<h4><a id="impl_producer" href="#impl_producer">Producer APIs</a></h4>
<p>
The Producer API that wraps the 2 low-level producers - <code>kafka.producer.SyncProducer</code> and <code>kafka.producer.async.AsyncProducer</code>.
@@ -68,7 +68,7 @@ The partition API uses the key and the number of available broker partitions to
</ul>
</p>
-<h4>Consumer APIs</h4>
+<h4><a id="impl_consumer" href="#impl_consumer">Consumer APIs</a></h4>
<p>
We have 2 levels of consumer APIs. The low-level "simple" API maintains a connection to a single broker and has a close correspondence to the network requests sent to the server. This API is completely stateless, with the offset being passed in on every request, allowing the user to maintain this metadata however they choose.
</p>
@@ -76,7 +76,7 @@ We have 2 levels of consumer APIs. The low-level "simple" API maintains a connec
The high-level API hides the details of brokers from the consumer and allows consuming off the cluster of machines without concern for the underlying topology. It also maintains the state of what has been consumed. The high-level API also provides the ability to subscribe to topics that match a filter expression (i.e., either a whitelist or a blacklist regular expression).
</p>
-<h5>Low-level API</h5>
+<h5><a id="impl_lowlevel" href="#impl_lowlevel">Low-level API</a></h5>
<pre>
class SimpleConsumer {
@@ -99,7 +99,7 @@ class SimpleConsumer {
The low-level API is used to implement the high-level API as well as being used directly for some of our offline consumers which have particular requirements around maintaining state.
-<h5>High-level API</h5>
+<h5><a id="impl_highlevel" href="#impl_highlevel">High-level API</a></h5>
<pre>
/* create a connection to the cluster */
@@ -138,15 +138,15 @@ This API is centered around iterators, implemented by the KafkaStream class. Eac
The createMessageStreams call registers the consumer for the topic, which results in rebalancing the consumer/broker assignment. The API encourages creating many topic streams in a single call in order to minimize this rebalancing. The createMessageStreamsByFilter call (additionally) registers watchers to discover new topics that match its filter. Note that each stream that createMessageStreamsByFilter returns may iterate over messages from multiple topics (i.e., if multiple topics are allowed by the filter).
</p>
-<h3><a id="networklayer">5.2 Network Layer</a></h3>
+<h3><a id="networklayer" href="#networklayer">5.2 Network Layer</a></h3>
<p>
The network layer is a fairly straight-forward NIO server, and will not be described in great detail. The sendfile implementation is done by giving the <code>MessageSet</code> interface a <code>writeTo</code> method. This allows the file-backed message set to use the more efficient <code>transferTo</code> implementation instead of an in-process buffered write. The threading model is a single acceptor thread and <i>N</i> processor threads which handle a fixed number of connections each. This design has been pretty thoroughly tested <a href="http://sna-projects.com/blog/2009/08/introducing-the-nio-socketserver-implementation">elsewhere</a> and found to be simple to implement and fast. The protocol is kept quite simple to allow for future implementation of clients in other languages.
</p>
-<h3><a id="messages">5.3 Messages</a></h3>
+<h3><a id="messages" href="#messages">5.3 Messages</a></h3>
<p>
Messages consist of a fixed-size header and variable length opaque byte array payload. The header contains a format version and a CRC32 checksum to detect corruption or truncation. Leaving the payload opaque is the right decision: there is a great deal of progress being made on serialization libraries right now, and any particular choice is unlikely to be right for all uses. Needless to say a particular application using Kafka would likely mandate a particular serialization type as part of its usage. The <code>MessageSet</code> interface is simply an iterator over messages with specialized methods for bulk reading and writing to an NIO <code>Channel</code>.
-<h3><a id="messageformat">5.4 Message Format</a></h3>
+<h3><a id="messageformat" href="#messageformat">5.4 Message Format</a></h3>
<pre>
/**
@@ -173,7 +173,7 @@ Messages consist of a fixed-size header and variable length opaque byte array pa
*/
</pre>
</p>
-<h3><a id="log">5.5 Log</a></h3>
+<h3><a id="log" href="#log">5.5 Log</a></h3>
<p>
A log for a topic named "my_topic" with two partitions consists of two directories (namely <code>my_topic_0</code> and <code>my_topic_1</code>) populated with data files containing the messages for that topic. The format of the log files is a sequence of "log entries""; each log entry is a 4 byte integer <i>N</i> storing the message length which is followed by the <i>N</i> message bytes. Each message is uniquely identified by a 64-bit integer <i>offset</i> giving the byte position of the start of this message in the stream of all messages ever sent to that topic on that partition. The on-disk format of each message is given below. Each log file is named with the offset of the first message it contains. So the first file created will be 00000000000.kafka, and each additional file will have an integer name roughly <i>S</i> bytes from the previous file where <i>S</i> is the max log file size given in the configuration.
</p>
@@ -192,11 +192,11 @@ payload : n bytes
The use of the message offset as the message id is unusual. Our original idea was to use a GUID generated by the producer, and maintain a mapping from GUID to offset on each broker. But since a consumer must maintain an ID for each server, the global uniqueness of the GUID provides no value. Furthermore the complexity of maintaining the mapping from a random id to an offset requires a heavy weight index structure which must be synchronized with disk, essentially requiring a full persistent random-access data structure. Thus to simplify the lookup structure we decided to use a simple per-partition atomic counter which could be coupled with the partition id and node id to uniquely identify a message; this makes the lookup structure simpler, though multiple seeks per consumer request are still likely. However once we settled on a counter, the jump to directly using the offset seemed natural—both after all are monotonically increasing integers unique to a partition. Since the offs
et is hidden from the consumer API this decision is ultimately an implementation detail and we went with the more efficient approach.
</p>
<img src="images/kafka_log.png">
-<h4>Writes</h4>
+<h4><a id="impl_writes" href="#impl_writes">Writes</a></h4>
<p>
The log allows serial appends which always go to the last file. This file is rolled over to a fresh file when it reaches a configurable size (say 1GB). The log takes two configuration parameter <i>M</i> which gives the number of messages to write before forcing the OS to flush the file to disk, and <i>S</i> which gives a number of seconds after which a flush is forced. This gives a durability guarantee of losing at most <i>M</i> messages or <i>S</i> seconds of data in the event of a system crash.
</p>
-<h4>Reads</h4>
+<h4><a id="impl_reads" href="#impl_reads">Reads</a></h4>
<p>
Reads are done by giving the 64-bit logical offset of a message and an <i>S</i>-byte max chunk size. This will return an iterator over the messages contained in the <i>S</i>-byte buffer. <i>S</i> is intended to be larger than any single message, but in the event of an abnormally large message, the read can be retried multiple times, each time doubling the buffer size, until the message is read successfully. A maximum message and buffer size can be specified to make the server reject messages larger than some size, and to give a bound to the client on the maximum it need ever read to get a complete message. It is likely that the read buffer ends with a partial message, this is easily detected by the size delimiting.
</p>
@@ -228,12 +228,11 @@ messageSetSend 1
...
messageSetSend n
</pre>
-
-<h4>Deletes</h4>
+<h4><a id="impl_deletes" href="#impl_deletes">Deletes</a></h4>
<p>
Data is deleted one log segment at a time. The log manager allows pluggable delete policies to choose which files are eligible for deletion. The current policy deletes any log with a modification time of more than <i>N</i> days ago, though a policy which retained the last <i>N</i> GB could also be useful. To avoid locking reads while still allowing deletes that modify the segment list we use a copy-on-write style segment list implementation that provides consistent views to allow a binary search to proceed on an immutable static snapshot view of the log segments while deletes are progressing.
</p>
-<h4>Guarantees</h4>
+<h4><a id="impl_guarantees" href="#impl_guarantees">Guarantees</a></h4>
<p>
The log provides a configuration parameter <i>M</i> which controls the maximum number of messages that are written before forcing a flush to disk. On startup a log recovery process is run that iterates over all messages in the newest log segment and verifies that each message entry is valid. A message entry is valid if the sum of its size and offset are less than the length of the file AND the CRC32 of the message payload matches the CRC stored with the message. In the event corruption is detected the log is truncated to the last valid offset.
</p>
@@ -241,8 +240,8 @@ The log provides a configuration parameter <i>M</i> which controls the maximum n
Note that two kinds of corruption must be handled: truncation in which an unwritten block is lost due to a crash, and corruption in which a nonsense block is ADDED to the file. The reason for this is that in general the OS makes no guarantee of the write order between the file inode and the actual block data so in addition to losing written data the file can gain nonsense data if the inode is updated with a new size but a crash occurs before the block containing that data is not written. The CRC detects this corner case, and prevents it from corrupting the log (though the unwritten messages are, of course, lost).
</p>
-<h3><a id="distributionimpl">5.6 Distribution</a></h3>
-<h4>Consumer Offset Tracking</h4>
+<h3><a id="distributionimpl" href="#distributionimpl">5.6 Distribution</a></h3>
+<h4><a id="impl_offsettracking" href="#impl_offsettracking">Consumer Offset Tracking</a></h4>
<p>
The high-level consumer tracks the maximum offset it has consumed in each partition and periodically commits its offset vector so that it can resume from those offsets in the event of a restart. Kafka provides the option to store all the offsets for a given consumer group in a designated broker (for that group) called the <i>offset manager</i>. i.e., any consumer instance in that consumer group should send its offset commits and fetches to that offset manager (broker). The high-level consumer handles this automatically. If you use the simple consumer you will need to manage offsets manually. This is currently unsupported in the Java simple consumer which can only commit or fetch offsets in ZooKeeper. If you use the Scala simple consumer you can discover the offset manager and explicitly commit or fetch offsets to the offset manager. A consumer can look up its offset manager by issuing a ConsumerMetadataRequest to any Kafka broker and reading the ConsumerMetadataResponse which will c
ontain the offset manager. The consumer can then proceed to commit or fetch offsets from the offsets manager broker. In case the offset manager moves, the consumer will need to rediscover the offset manager. If you wish to manage your offsets manually, you can take a look at these <a href="https://cwiki.apache.org/confluence/display/KAFKA/Committing+and+fetching+consumer+offsets+in+Kafka">code samples that explain how to issue OffsetCommitRequest and OffsetFetchRequest</a>.
</p>
@@ -255,7 +254,7 @@ When the offset manager receives an OffsetCommitRequest, it appends the request
When the offset manager receives an offset fetch request, it simply returns the last committed offset vector from the offsets cache. In case the offset manager was just started or if it just became the offset manager for a new set of consumer groups (by becoming a leader for a partition of the offsets topic), it may need to load the offsets topic partition into the cache. In this case, the offset fetch will fail with an OffsetsLoadInProgress exception and the consumer may retry the OffsetFetchRequest after backing off. (This is done automatically by the high-level consumer.)
</p>
-<h5><a id="offsetmigration">Migrating offsets from ZooKeeper to Kafka</a></h5>
+<h5><a id="offsetmigration" href="#offsetmigration">Migrating offsets from ZooKeeper to Kafka</a></h5>
<p>
Kafka consumers in earlier releases store their offsets by default in ZooKeeper. It is possible to migrate these consumers to commit offsets into Kafka by following these steps:
<ol>
@@ -271,17 +270,17 @@ Kafka consumers in earlier releases store their offsets by default in ZooKeeper.
A roll-back (i.e., migrating from Kafka back to ZooKeeper) can also be performed using the above steps if you set <code>offsets.storage=zookeeper</code>.
</p>
-<h4>ZooKeeper Directories</h4>
+<h4><a id="impl_zookeeper" href="#impl_zookeeper">ZooKeeper Directories</a></h4>
<p>
The following gives the ZooKeeper structures and algorithms used for co-ordination between consumers and brokers.
</p>
-<h4>Notation</h4>
+<h4><a id="impl_zknotation" href="#impl_zknotation">Notation</a></h4>
<p>
When an element in a path is denoted [xyz], that means that the value of xyz is not fixed and there is in fact a ZooKeeper znode for each possible value of xyz. For example /topics/[topic] would be a directory named /topics containing a sub-directory for each topic name. Numerical ranges are also given such as [0...5] to indicate the subdirectories 0, 1, 2, 3, 4. An arrow -> is used to indicate the contents of a znode. For example /hello -> world would indicate a znode /hello containing the value "world".
</p>
-<h4>Broker Node Registry</h4>
+<h4><a id="impl_zkbroker" href="#impl_zkbroker">Broker Node Registry</a></h4>
<pre>
/brokers/ids/[0...N] --> host:port (ephemeral node)
</pre>
@@ -291,7 +290,7 @@ This is a list of all present broker nodes, each of which provides a unique logi
<p>
Since the broker registers itself in ZooKeeper using ephemeral znodes, this registration is dynamic and will disappear if the broker is shutdown or dies (thus notifying consumers it is no longer available).
</p>
-<h4>Broker Topic Registry</h4>
+<h4><a id="impl_zktopic" href="#impl_zktopic">Broker Topic Registry</a></h4>
<pre>
/brokers/topics/[topic]/[0...N] --> nPartions (ephemeral node)
</pre>
@@ -300,7 +299,7 @@ Since the broker registers itself in ZooKeeper using ephemeral znodes, this regi
Each broker registers itself under the topics it maintains and stores the number of partitions for that topic.
</p>
-<h4>Consumers and Consumer Groups</h4>
+<h4><a id="impl_zkconsumers" href="#impl_zkconsumers">Consumers and Consumer Groups</a></h4>
<p>
Consumers of topics also register themselves in ZooKeeper, in order to coordinate with each other and balance the consumption of data. Consumers can also store their offsets in ZooKeeper by setting <code>offsets.storage=zookeeper</code>. However, this offset storage mechanism will be deprecated in a future release. Therefore, it is recommended to <a href="#offsetmigration">migrate offsets storage to Kafka</a>.
</p>
@@ -314,7 +313,7 @@ For example if one consumer is your foobar process, which is run across three ma
The consumers in a group divide up the partitions as fairly as possible, each partition is consumed by exactly one consumer in a consumer group.
</p>
-<h4>Consumer Id Registry</h4>
+<h4><a id="impl_zkconsumerid" href="#impl_zkconsumerid">Consumer Id Registry</a></h4>
<p>
In addition to the group_id which is shared by all consumers in a group, each consumer is given a transient, unique consumer_id (of the form hostname:uuid) for identification purposes. Consumer ids are registered in the following directory.
<pre>
@@ -323,7 +322,7 @@ In addition to the group_id which is shared by all consumers in a group, each co
Each of the consumers in the group registers under its group and creates a znode with its consumer_id. The value of the znode contains a map of <topic, #streams>. This id is simply used to identify each of the consumers which is currently active within a group. This is an ephemeral node so it will disappear if the consumer process dies.
</p>
-<h4>Consumer Offsets</h4>
+<h4><a id="impl_zkconsumeroffsets" href="#impl_zkconsumeroffsets">Consumer Offsets</a></h4>
<p>
Consumers track the maximum offset they have consumed in each partition. This value is stored in a ZooKeeper directory if <code>offsets.storage=zookeeper</code>. This valued is stored in a ZooKeeper directory.
</p>
@@ -331,7 +330,7 @@ Consumers track the maximum offset they have consumed in each partition. This va
/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id] --> offset_counter_value ((persistent node)
</pre>
-<h4>Partition Owner registry</h4>
+<h4><a id="impl_zkowner" href="#impl_zkowner">Partition Owner registry</a></h4>
<p>
Each broker partition is consumed by a single consumer within a given consumer group. The consumer must establish its ownership of a given partition before any consumption can begin. To establish its ownership, a consumer writes its own id in an ephemeral node under the particular broker partition it is claiming.
@@ -341,13 +340,13 @@ Each broker partition is consumed by a single consumer within a given consumer g
/consumers/[group_id]/owners/[topic]/[broker_id-partition_id] --> consumer_node_id (ephemeral node)
</pre>
-<h4>Broker node registration</h4>
+<h4><a id="impl_brokerregistration" href="#impl_brokerregistration">Broker node registration</a></h4>
<p>
The broker nodes are basically independent, so they only publish information about what they have. When a broker joins, it registers itself under the broker node registry directory and writes information about its host name and port. The broker also register the list of existing topics and their logical partitions in the broker topic registry. New topics are registered dynamically when they are created on the broker.
</p>
-<h4>Consumer registration algorithm</h4>
+<h4><a id="impl_consumerregistration" href="#impl_consumerregistration">Consumer registration algorithm</a></h4>
<p>
When a consumer starts, it does the following:
@@ -363,7 +362,7 @@ When a consumer starts, it does the following:
</ol>
</p>
-<h4>Consumer rebalancing algorithm</h4>
+<h4><a id="impl_consumerrebalance" href="#impl_consumerrebalance">Consumer rebalancing algorithm</a></h4>
<p>
The consumer rebalancing algorithms allows all the consumers in a group to come into consensus on which consumer is consuming which partitions. Consumer rebalancing is triggered on each addition or removal of both broker nodes and other consumers within the same group. For a given topic and a given consumer group, broker partitions are divided evenly among consumers within the group. A partition is always consumed by a single consumer. This design simplifies the implementation. Had we allowed a partition to be concurrently consumed by multiple consumers, there would be contention on the partition and some kind of locking would be required. If there are more consumers than partitions, some consumers won't get any data at all. During rebalancing, we try to assign partitions to consumers in such a way that reduces the number of broker nodes each consumer has to connect to.
</p>