You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@kafka.apache.org by gw...@apache.org on 2016/10/04 22:56:20 UTC
[4/6] kafka-site git commit: new design
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/1b8cdf48/081/documentation.html
----------------------------------------------------------------------
diff --git a/081/documentation.html b/081/documentation.html
index bf13362..7fbb41d 100644
--- a/081/documentation.html
+++ b/081/documentation.html
@@ -1,116 +1,120 @@
<!--#include virtual="../includes/header.html" -->
+<!--#include virtual="../includes/top.html" -->
+<div class="content">
+ <!--#include virtual="../includes/nav.html" -->
+ <div class="right">
+ <h1>Documentation</h1>
+ <h3>Kafka 0.8.1</h3>
+ Prior releases: <a href="/07/documentation.html">0.7.x</a>, <a href="/08/documentation.html">0.8.0</a>.
+ </ul>
-<h1>Kafka 0.8.1 Documentation</h1>
-Prior releases: <a href="/07/documentation.html">0.7.x</a>, <a href="/08/documentation.html">0.8.0</a>.
-</ul>
-
-<ul class="toc">
- <li><a href="#gettingStarted">1. Getting Started</a>
- <ul>
- <li><a href="#introduction">1.1 Introduction</a>
- <li><a href="#uses">1.2 Use Cases</a>
- <li><a href="#quickstart">1.3 Quick Start</a>
- <li><a href="#ecosystem">1.4 Ecosystem</a>
- <li><a href="#upgrade">1.5 Upgrading</a>
- </ul>
- <li><a href="#api">2. API</a>
- <ul>
- <li><a href="#producerapi">2.1 Producer API</a>
- <li><a href="#highlevelconsumerapi">2.2 High Level Consumer API</a>
- <li><a href="#simpleconsumerapi">2.3 Simple Consumer API</a>
- <li><a href="#kafkahadoopconsumerapi">2.4 Kafka Hadoop Consumer API</a>
- </ul>
- <li><a href="#configuration">3. Configuration</a>
- <ul>
- <li><a href="#brokerconfigs">3.1 Broker Configs</a>
- <li><a href="#consumerconfigs">3.2 Consumer Configs</a>
- <li><a href="#producerconfigs">3.3 Producer Configs</a>
- <li><a href="#newproducerconfigs">3.4 New Producer Configs</a>
- </ul>
- <li><a href="#design">4. Design</a>
- <ul>
- <li><a href="#majordesignelements">4.1 Motivation</a>
- <li><a href="#persistence">4.2 Persistence</a>
- <li><a href="#maximizingefficiency">4.3 Efficiency</a>
- <li><a href="#theproducer">4.4 The Producer</a>
- <li><a href="#theconsumer">4.5 The Consumer</a>
- <li><a href="#semantics">4.6 Message Delivery Semantics</a>
- <li><a href="#replication">4.7 Replication</a>
- <li><a href="#compaction">4.8 Log Compaction</a>
- </ul>
- <li><a href="#implementation">5. Implementation</a>
- <ul>
- <li><a href="#apidesign">5.1 API Design</a>
- <li><a href="#networklayer">5.2 Network Layer</a>
- <li><a href="#messages">5.3 Messages</a>
- <li><a href="#messageformat">5.4 Message format</a>
- <li><a href="#log">5.5 Log</a>
- <li><a href="#distributionimpl">5.6 Distribution</a>
- </ul>
- <li><a href="#operations">6. Operations</a>
- <ul>
- <li><a href="#basic_ops">6.1 Basic Kafka Operations</a>
- <ul>
- <li><a href="#basic_ops_add_topic">Adding and removing topics</a>
- <li><a href="#basic_ops_modify_topic">Modifying topics</a>
- <li><a href="#basic_ops_restarting">Graceful shutdown</a>
- <li><a href="#basic_ops_leader_balancing">Balancing leadership</a>
- <li><a href="#basic_ops_consumer_lag">Checking consumer position</a>
- <li><a href="#basic_ops_mirror_maker">Mirroring data between clusters</a>
- <li><a href="#basic_ops_cluster_expansion">Expanding your cluster</a>
- <li><a href="#basic_ops_decommissioning_brokers">Decommissioning brokers</a>
- <li><a href="#basic_ops_increase_replication_factor">Increasing replication factor</a>
- </ul>
- <li><a href="#datacenters">6.2 Datacenters</a>
- <li><a href="#config">6.3 Important Configs</a>
- <ul>
- <li><a href="#serverconfig">Important Server Configs</a>
- <li><a href="#clientconfig">Important Client Configs</a>
- <li><a href="#prodconfig">A Production Server Configs</a>
- </ul>
- <li><a href="#java">6.4 Java Version</a>
- <li><a href="#hwandos">6.5 Hardware and OS</a>
- <ul>
- <li><a href="#os">OS</a>
- <li><a href="#diskandfs">Disks and Filesystems</a>
- <li><a href="#appvsosflush">Application vs OS Flush Management</a>
- <li><a href="#linuxflush">Linux Flush Behavior</a>
- <li><a href="#ext4">Ext4 Notes</a>
- </ul>
- <li><a href="#monitoring">6.6 Monitoring</a>
- <li><a href="#zk">6.7 ZooKeeper</a>
- <ul>
- <li><a href="#zkversion">Stable Version</a>
- <li><a href="#zkops">Operationalization</a>
- </ul>
- </ul>
-</ul>
+ <ul class="toc">
+ <li><a href="#gettingStarted">1. Getting Started</a>
+ <ul>
+ <li><a href="#introduction">1.1 Introduction</a>
+ <li><a href="#uses">1.2 Use Cases</a>
+ <li><a href="#quickstart">1.3 Quick Start</a>
+ <li><a href="#ecosystem">1.4 Ecosystem</a>
+ <li><a href="#upgrade">1.5 Upgrading</a>
+ </ul>
+ <li><a href="#api">2. API</a>
+ <ul>
+ <li><a href="#producerapi">2.1 Producer API</a>
+ <li><a href="#highlevelconsumerapi">2.2 High Level Consumer API</a>
+ <li><a href="#simpleconsumerapi">2.3 Simple Consumer API</a>
+ <li><a href="#kafkahadoopconsumerapi">2.4 Kafka Hadoop Consumer API</a>
+ </ul>
+ <li><a href="#configuration">3. Configuration</a>
+ <ul>
+ <li><a href="#brokerconfigs">3.1 Broker Configs</a>
+ <li><a href="#consumerconfigs">3.2 Consumer Configs</a>
+ <li><a href="#producerconfigs">3.3 Producer Configs</a>
+ <li><a href="#newproducerconfigs">3.4 New Producer Configs</a>
+ </ul>
+ <li><a href="#design">4. Design</a>
+ <ul>
+ <li><a href="#majordesignelements">4.1 Motivation</a>
+ <li><a href="#persistence">4.2 Persistence</a>
+ <li><a href="#maximizingefficiency">4.3 Efficiency</a>
+ <li><a href="#theproducer">4.4 The Producer</a>
+ <li><a href="#theconsumer">4.5 The Consumer</a>
+ <li><a href="#semantics">4.6 Message Delivery Semantics</a>
+ <li><a href="#replication">4.7 Replication</a>
+ <li><a href="#compaction">4.8 Log Compaction</a>
+ </ul>
+ <li><a href="#implementation">5. Implementation</a>
+ <ul>
+ <li><a href="#apidesign">5.1 API Design</a>
+ <li><a href="#networklayer">5.2 Network Layer</a>
+ <li><a href="#messages">5.3 Messages</a>
+ <li><a href="#messageformat">5.4 Message format</a>
+ <li><a href="#log">5.5 Log</a>
+ <li><a href="#distributionimpl">5.6 Distribution</a>
+ </ul>
+ <li><a href="#operations">6. Operations</a>
+ <ul>
+ <li><a href="#basic_ops">6.1 Basic Kafka Operations</a>
+ <ul>
+ <li><a href="#basic_ops_add_topic">Adding and removing topics</a>
+ <li><a href="#basic_ops_modify_topic">Modifying topics</a>
+ <li><a href="#basic_ops_restarting">Graceful shutdown</a>
+ <li><a href="#basic_ops_leader_balancing">Balancing leadership</a>
+ <li><a href="#basic_ops_consumer_lag">Checking consumer position</a>
+ <li><a href="#basic_ops_mirror_maker">Mirroring data between clusters</a>
+ <li><a href="#basic_ops_cluster_expansion">Expanding your cluster</a>
+ <li><a href="#basic_ops_decommissioning_brokers">Decommissioning brokers</a>
+ <li><a href="#basic_ops_increase_replication_factor">Increasing replication factor</a>
+ </ul>
+ <li><a href="#datacenters">6.2 Datacenters</a>
+ <li><a href="#config">6.3 Important Configs</a>
+ <ul>
+ <li><a href="#serverconfig">Important Server Configs</a>
+ <li><a href="#clientconfig">Important Client Configs</a>
+ <li><a href="#prodconfig">A Production Server Configs</a>
+ </ul>
+ <li><a href="#java">6.4 Java Version</a>
+ <li><a href="#hwandos">6.5 Hardware and OS</a>
+ <ul>
+ <li><a href="#os">OS</a>
+ <li><a href="#diskandfs">Disks and Filesystems</a>
+ <li><a href="#appvsosflush">Application vs OS Flush Management</a>
+ <li><a href="#linuxflush">Linux Flush Behavior</a>
+ <li><a href="#ext4">Ext4 Notes</a>
+ </ul>
+ <li><a href="#monitoring">6.6 Monitoring</a>
+ <li><a href="#zk">6.7 ZooKeeper</a>
+ <ul>
+ <li><a href="#zkversion">Stable Version</a>
+ <li><a href="#zkops">Operationalization</a>
+ </ul>
+ </ul>
+ </ul>
-<h2><a id="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="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">2. API</a></h2>
-<!--#include virtual="api.html" -->
+ <!--#include virtual="api.html" -->
-<h2><a id="configuration">3. Configuration</a></h2>
+ <h2><a id="configuration">3. Configuration</a></h2>
-<!--#include virtual="configuration.html" -->
+ <!--#include virtual="configuration.html" -->
-<h2><a id="design">4. Design</a></h2>
+ <h2><a id="design">4. Design</a></h2>
-<!--#include virtual="design.html" -->
+ <!--#include virtual="design.html" -->
-<h2><a id="implementation">5. Implementation</a></h2>
+ <h2><a id="implementation">5. Implementation</a></h2>
-<!--#include virtual="implementation.html" -->
+ <!--#include virtual="implementation.html" -->
-<h2><a id="operations">6. Operations</a></h2>
+ <h2><a id="operations">6. Operations</a></h2>
-<!--#include virtual="ops.html" -->
+ <!--#include virtual="ops.html" -->
<!--#include virtual="../includes/footer.html" -->
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/1b8cdf48/082/documentation.html
----------------------------------------------------------------------
diff --git a/082/documentation.html b/082/documentation.html
index 52199d7..6c6aea9 100644
--- a/082/documentation.html
+++ b/082/documentation.html
@@ -1,116 +1,120 @@
<!--#include virtual="../includes/header.html" -->
+<!--#include virtual="../includes/top.html" -->
+<div class="content">
+ <!--#include virtual="../includes/nav.html" -->
+ <div class="right">
+ <h1>Documentation</h1>
+ <h3>Kafka 0.8.2</h3>
+ Prior releases: <a href="/07/documentation.html">0.7.x</a>, <a href="/08/documentation.html">0.8.0</a>, <a href="/081/documentation.html">0.8.1.X</a>.
+ </ul>
-<h1>Kafka 0.8.2 Documentation</h1>
-Prior releases: <a href="/07/documentation.html">0.7.x</a>, <a href="/08/documentation.html">0.8.0</a>, <a href="/081/documentation.html">0.8.1.X</a>.
-</ul>
-
-<ul class="toc">
- <li><a href="#gettingStarted">1. Getting Started</a>
- <ul>
- <li><a href="#introduction">1.1 Introduction</a>
- <li><a href="#uses">1.2 Use Cases</a>
- <li><a href="#quickstart">1.3 Quick Start</a>
- <li><a href="#ecosystem">1.4 Ecosystem</a>
- <li><a href="#upgrade">1.5 Upgrading</a>
- </ul>
- <li><a href="#api">2. API</a>
- <ul>
- <li><a href="#producerapi">2.1 Producer API</a>
- <li><a href="#highlevelconsumerapi">2.2 High Level Consumer API</a>
- <li><a href="#simpleconsumerapi">2.3 Simple Consumer API</a>
- <li><a href="#kafkahadoopconsumerapi">2.4 Kafka Hadoop Consumer API</a>
- </ul>
- <li><a href="#configuration">3. Configuration</a>
- <ul>
- <li><a href="#brokerconfigs">3.1 Broker Configs</a>
- <li><a href="#consumerconfigs">3.2 Consumer Configs</a>
- <li><a href="#producerconfigs">3.3 Producer Configs</a>
- <li><a href="#newproducerconfigs">3.4 New Producer Configs</a>
- </ul>
- <li><a href="#design">4. Design</a>
- <ul>
- <li><a href="#majordesignelements">4.1 Motivation</a>
- <li><a href="#persistence">4.2 Persistence</a>
- <li><a href="#maximizingefficiency">4.3 Efficiency</a>
- <li><a href="#theproducer">4.4 The Producer</a>
- <li><a href="#theconsumer">4.5 The Consumer</a>
- <li><a href="#semantics">4.6 Message Delivery Semantics</a>
- <li><a href="#replication">4.7 Replication</a>
- <li><a href="#compaction">4.8 Log Compaction</a>
- </ul>
- <li><a href="#implementation">5. Implementation</a>
- <ul>
- <li><a href="#apidesign">5.1 API Design</a>
- <li><a href="#networklayer">5.2 Network Layer</a>
- <li><a href="#messages">5.3 Messages</a>
- <li><a href="#messageformat">5.4 Message format</a>
- <li><a href="#log">5.5 Log</a>
- <li><a href="#distributionimpl">5.6 Distribution</a>
- </ul>
- <li><a href="#operations">6. Operations</a>
- <ul>
- <li><a href="#basic_ops">6.1 Basic Kafka Operations</a>
- <ul>
- <li><a href="#basic_ops_add_topic">Adding and removing topics</a>
- <li><a href="#basic_ops_modify_topic">Modifying topics</a>
- <li><a href="#basic_ops_restarting">Graceful shutdown</a>
- <li><a href="#basic_ops_leader_balancing">Balancing leadership</a>
- <li><a href="#basic_ops_consumer_lag">Checking consumer position</a>
- <li><a href="#basic_ops_mirror_maker">Mirroring data between clusters</a>
- <li><a href="#basic_ops_cluster_expansion">Expanding your cluster</a>
- <li><a href="#basic_ops_decommissioning_brokers">Decommissioning brokers</a>
- <li><a href="#basic_ops_increase_replication_factor">Increasing replication factor</a>
- </ul>
- <li><a href="#datacenters">6.2 Datacenters</a>
- <li><a href="#config">6.3 Important Configs</a>
- <ul>
- <li><a href="#serverconfig">Important Server Configs</a>
- <li><a href="#clientconfig">Important Client Configs</a>
- <li><a href="#prodconfig">A Production Server Configs</a>
- </ul>
- <li><a href="#java">6.4 Java Version</a>
- <li><a href="#hwandos">6.5 Hardware and OS</a>
- <ul>
- <li><a href="#os">OS</a>
- <li><a href="#diskandfs">Disks and Filesystems</a>
- <li><a href="#appvsosflush">Application vs OS Flush Management</a>
- <li><a href="#linuxflush">Linux Flush Behavior</a>
- <li><a href="#ext4">Ext4 Notes</a>
- </ul>
- <li><a href="#monitoring">6.6 Monitoring</a>
- <li><a href="#zk">6.7 ZooKeeper</a>
- <ul>
- <li><a href="#zkversion">Stable Version</a>
- <li><a href="#zkops">Operationalization</a>
- </ul>
- </ul>
-</ul>
+ <ul class="toc">
+ <li><a href="#gettingStarted">1. Getting Started</a>
+ <ul>
+ <li><a href="#introduction">1.1 Introduction</a>
+ <li><a href="#uses">1.2 Use Cases</a>
+ <li><a href="#quickstart">1.3 Quick Start</a>
+ <li><a href="#ecosystem">1.4 Ecosystem</a>
+ <li><a href="#upgrade">1.5 Upgrading</a>
+ </ul>
+ <li><a href="#api">2. API</a>
+ <ul>
+ <li><a href="#producerapi">2.1 Producer API</a>
+ <li><a href="#highlevelconsumerapi">2.2 High Level Consumer API</a>
+ <li><a href="#simpleconsumerapi">2.3 Simple Consumer API</a>
+ <li><a href="#kafkahadoopconsumerapi">2.4 Kafka Hadoop Consumer API</a>
+ </ul>
+ <li><a href="#configuration">3. Configuration</a>
+ <ul>
+ <li><a href="#brokerconfigs">3.1 Broker Configs</a>
+ <li><a href="#consumerconfigs">3.2 Consumer Configs</a>
+ <li><a href="#producerconfigs">3.3 Producer Configs</a>
+ <li><a href="#newproducerconfigs">3.4 New Producer Configs</a>
+ </ul>
+ <li><a href="#design">4. Design</a>
+ <ul>
+ <li><a href="#majordesignelements">4.1 Motivation</a>
+ <li><a href="#persistence">4.2 Persistence</a>
+ <li><a href="#maximizingefficiency">4.3 Efficiency</a>
+ <li><a href="#theproducer">4.4 The Producer</a>
+ <li><a href="#theconsumer">4.5 The Consumer</a>
+ <li><a href="#semantics">4.6 Message Delivery Semantics</a>
+ <li><a href="#replication">4.7 Replication</a>
+ <li><a href="#compaction">4.8 Log Compaction</a>
+ </ul>
+ <li><a href="#implementation">5. Implementation</a>
+ <ul>
+ <li><a href="#apidesign">5.1 API Design</a>
+ <li><a href="#networklayer">5.2 Network Layer</a>
+ <li><a href="#messages">5.3 Messages</a>
+ <li><a href="#messageformat">5.4 Message format</a>
+ <li><a href="#log">5.5 Log</a>
+ <li><a href="#distributionimpl">5.6 Distribution</a>
+ </ul>
+ <li><a href="#operations">6. Operations</a>
+ <ul>
+ <li><a href="#basic_ops">6.1 Basic Kafka Operations</a>
+ <ul>
+ <li><a href="#basic_ops_add_topic">Adding and removing topics</a>
+ <li><a href="#basic_ops_modify_topic">Modifying topics</a>
+ <li><a href="#basic_ops_restarting">Graceful shutdown</a>
+ <li><a href="#basic_ops_leader_balancing">Balancing leadership</a>
+ <li><a href="#basic_ops_consumer_lag">Checking consumer position</a>
+ <li><a href="#basic_ops_mirror_maker">Mirroring data between clusters</a>
+ <li><a href="#basic_ops_cluster_expansion">Expanding your cluster</a>
+ <li><a href="#basic_ops_decommissioning_brokers">Decommissioning brokers</a>
+ <li><a href="#basic_ops_increase_replication_factor">Increasing replication factor</a>
+ </ul>
+ <li><a href="#datacenters">6.2 Datacenters</a>
+ <li><a href="#config">6.3 Important Configs</a>
+ <ul>
+ <li><a href="#serverconfig">Important Server Configs</a>
+ <li><a href="#clientconfig">Important Client Configs</a>
+ <li><a href="#prodconfig">A Production Server Configs</a>
+ </ul>
+ <li><a href="#java">6.4 Java Version</a>
+ <li><a href="#hwandos">6.5 Hardware and OS</a>
+ <ul>
+ <li><a href="#os">OS</a>
+ <li><a href="#diskandfs">Disks and Filesystems</a>
+ <li><a href="#appvsosflush">Application vs OS Flush Management</a>
+ <li><a href="#linuxflush">Linux Flush Behavior</a>
+ <li><a href="#ext4">Ext4 Notes</a>
+ </ul>
+ <li><a href="#monitoring">6.6 Monitoring</a>
+ <li><a href="#zk">6.7 ZooKeeper</a>
+ <ul>
+ <li><a href="#zkversion">Stable Version</a>
+ <li><a href="#zkops">Operationalization</a>
+ </ul>
+ </ul>
+ </ul>
-<h2><a id="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="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">2. API</a></h2>
-<!--#include virtual="api.html" -->
+ <!--#include virtual="api.html" -->
-<h2><a id="configuration">3. Configuration</a></h2>
+ <h2><a id="configuration">3. Configuration</a></h2>
-<!--#include virtual="configuration.html" -->
+ <!--#include virtual="configuration.html" -->
-<h2><a id="design">4. Design</a></h2>
+ <h2><a id="design">4. Design</a></h2>
-<!--#include virtual="design.html" -->
+ <!--#include virtual="design.html" -->
-<h2><a id="implementation">5. Implementation</a></h2>
+ <h2><a id="implementation">5. Implementation</a></h2>
-<!--#include virtual="implementation.html" -->
+ <!--#include virtual="implementation.html" -->
-<h2><a id="operations">6. Operations</a></h2>
+ <h2><a id="operations">6. Operations</a></h2>
-<!--#include virtual="ops.html" -->
+ <!--#include virtual="ops.html" -->
<!--#include virtual="../includes/footer.html" -->
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/1b8cdf48/090/documentation.html
----------------------------------------------------------------------
diff --git a/090/documentation.html b/090/documentation.html
index 4ce7599..bae0652 100644
--- a/090/documentation.html
+++ b/090/documentation.html
@@ -16,159 +16,163 @@
-->
<!--#include virtual="../includes/header.html" -->
-
-<h1>Kafka 0.9.0 Documentation</h1>
-Prior releases: <a href="/07/documentation.html">0.7.x</a>, <a href="/08/documentation.html">0.8.0</a>, <a href="/081/documentation.html">0.8.1.X</a>, <a href="/082/documentation.html">0.8.2.X</a>.
-</ul>
-
-<ul class="toc">
- <li><a href="#gettingStarted">1. Getting Started</a>
- <ul>
- <li><a href="#introduction">1.1 Introduction</a>
- <li><a href="#uses">1.2 Use Cases</a>
- <li><a href="#quickstart">1.3 Quick Start</a>
- <li><a href="#ecosystem">1.4 Ecosystem</a>
- <li><a href="#upgrade">1.5 Upgrading</a>
- </ul>
- </li>
- <li><a href="#api">2. API</a>
- <ul>
- <li><a href="#producerapi">2.1 Producer API</a>
- <li><a href="#consumerapi">2.2 Consumer API</a>
- <ul>
- <li><a href="#highlevelconsumerapi">2.2.1 Old High Level Consumer API</a>
- <li><a href="#simpleconsumerapi">2.2.2 Old Simple Consumer API</a>
- <li><a href="#newconsumerapi">2.2.3 New Consumer API</a>
- </ul>
- </ul>
- </li>
- <li><a href="#configuration">3. Configuration</a>
- <ul>
- <li><a href="#brokerconfigs">3.1 Broker Configs</a>
- <li><a href="#producerconfigs">3.2 Producer Configs</a>
- <li><a href="#consumerconfigs">3.3 Consumer Configs</a>
- <ul>
- <li><a href="#oldconsumerconfigs">3.3.1 Old Consumer Configs</a>
- <li><a href="#newconsumerconfigs">3.3.2 New Consumer Configs</a>
- </ul>
- <li><a href="#connectconfigs">3.4 Kafka Connect Configs</a>
- </ul>
- </li>
- <li><a href="#design">4. Design</a>
- <ul>
- <li><a href="#majordesignelements">4.1 Motivation</a>
- <li><a href="#persistence">4.2 Persistence</a>
- <li><a href="#maximizingefficiency">4.3 Efficiency</a>
- <li><a href="#theproducer">4.4 The Producer</a>
- <li><a href="#theconsumer">4.5 The Consumer</a>
- <li><a href="#semantics">4.6 Message Delivery Semantics</a>
- <li><a href="#replication">4.7 Replication</a>
- <li><a href="#compaction">4.8 Log Compaction</a>
- <li><a href="#design_quotas">4.9 Quotas</a>
- </ul>
- </li>
- <li><a href="#implementation">5. Implementation</a>
- <ul>
- <li><a href="#apidesign">5.1 API Design</a>
- <li><a href="#networklayer">5.2 Network Layer</a>
- <li><a href="#messages">5.3 Messages</a>
- <li><a href="#messageformat">5.4 Message format</a>
- <li><a href="#log">5.5 Log</a>
- <li><a href="#distributionimpl">5.6 Distribution</a>
- </ul>
- </li>
- <li><a href="#operations">6. Operations</a>
- <ul>
- <li><a href="#basic_ops">6.1 Basic Kafka Operations</a>
- <ul>
- <li><a href="#basic_ops_add_topic">Adding and removing topics</a>
- <li><a href="#basic_ops_modify_topic">Modifying topics</a>
- <li><a href="#basic_ops_restarting">Graceful shutdown</a>
- <li><a href="#basic_ops_leader_balancing">Balancing leadership</a>
- <li><a href="#basic_ops_consumer_lag">Checking consumer position</a>
- <li><a href="#basic_ops_mirror_maker">Mirroring data between clusters</a>
- <li><a href="#basic_ops_cluster_expansion">Expanding your cluster</a>
- <li><a href="#basic_ops_decommissioning_brokers">Decommissioning brokers</a>
- <li><a href="#basic_ops_increase_replication_factor">Increasing replication factor</a>
- </ul>
- <li><a href="#datacenters">6.2 Datacenters</a>
- <li><a href="#config">6.3 Important Configs</a>
- <ul>
- <li><a href="#serverconfig">Important Server Configs</a>
- <li><a href="#clientconfig">Important Client Configs</a>
- <li><a href="#prodconfig">A Production Server Configs</a>
- </ul>
- <li><a href="#java">6.4 Java Version</a>
- <li><a href="#hwandos">6.5 Hardware and OS</a>
- <ul>
- <li><a href="#os">OS</a>
- <li><a href="#diskandfs">Disks and Filesystems</a>
- <li><a href="#appvsosflush">Application vs OS Flush Management</a>
- <li><a href="#linuxflush">Linux Flush Behavior</a>
- <li><a href="#ext4">Ext4 Notes</a>
- </ul>
- <li><a href="#monitoring">6.6 Monitoring</a>
- <li><a href="#zk">6.7 ZooKeeper</a>
+<!--#include virtual="../includes/top.html" -->
+<div class="content">
+ <!--#include virtual="../includes/nav.html" -->
+ <div class="right">
+ <h1>Documentation</h1>
+ <h3>Kafka 0.9.0</h3>
+ Prior releases: <a href="/07/documentation.html">0.7.x</a>, <a href="/08/documentation.html">0.8.0</a>, <a href="/081/documentation.html">0.8.1.X</a>, <a href="/082/documentation.html">0.8.2.X</a>.
+ </ul>
+
+ <ul class="toc">
+ <li><a href="#gettingStarted">1. Getting Started</a>
+ <ul>
+ <li><a href="#introduction">1.1 Introduction</a>
+ <li><a href="#uses">1.2 Use Cases</a>
+ <li><a href="#quickstart">1.3 Quick Start</a>
+ <li><a href="#ecosystem">1.4 Ecosystem</a>
+ <li><a href="#upgrade">1.5 Upgrading</a>
+ </ul>
+ </li>
+ <li><a href="#api">2. API</a>
+ <ul>
+ <li><a href="#producerapi">2.1 Producer API</a>
+ <li><a href="#consumerapi">2.2 Consumer API</a>
+ <ul>
+ <li><a href="#highlevelconsumerapi">2.2.1 Old High Level Consumer API</a>
+ <li><a href="#simpleconsumerapi">2.2.2 Old Simple Consumer API</a>
+ <li><a href="#newconsumerapi">2.2.3 New Consumer API</a>
+ </ul>
+ </ul>
+ </li>
+ <li><a href="#configuration">3. Configuration</a>
+ <ul>
+ <li><a href="#brokerconfigs">3.1 Broker Configs</a>
+ <li><a href="#producerconfigs">3.2 Producer Configs</a>
+ <li><a href="#consumerconfigs">3.3 Consumer Configs</a>
+ <ul>
+ <li><a href="#oldconsumerconfigs">3.3.1 Old Consumer Configs</a>
+ <li><a href="#newconsumerconfigs">3.3.2 New Consumer Configs</a>
+ </ul>
+ <li><a href="#connectconfigs">3.4 Kafka Connect Configs</a>
+ </ul>
+ </li>
+ <li><a href="#design">4. Design</a>
+ <ul>
+ <li><a href="#majordesignelements">4.1 Motivation</a>
+ <li><a href="#persistence">4.2 Persistence</a>
+ <li><a href="#maximizingefficiency">4.3 Efficiency</a>
+ <li><a href="#theproducer">4.4 The Producer</a>
+ <li><a href="#theconsumer">4.5 The Consumer</a>
+ <li><a href="#semantics">4.6 Message Delivery Semantics</a>
+ <li><a href="#replication">4.7 Replication</a>
+ <li><a href="#compaction">4.8 Log Compaction</a>
+ <li><a href="#design_quotas">4.9 Quotas</a>
+ </ul>
+ </li>
+ <li><a href="#implementation">5. Implementation</a>
+ <ul>
+ <li><a href="#apidesign">5.1 API Design</a>
+ <li><a href="#networklayer">5.2 Network Layer</a>
+ <li><a href="#messages">5.3 Messages</a>
+ <li><a href="#messageformat">5.4 Message format</a>
+ <li><a href="#log">5.5 Log</a>
+ <li><a href="#distributionimpl">5.6 Distribution</a>
+ </ul>
+ </li>
+ <li><a href="#operations">6. Operations</a>
+ <ul>
+ <li><a href="#basic_ops">6.1 Basic Kafka Operations</a>
+ <ul>
+ <li><a href="#basic_ops_add_topic">Adding and removing topics</a>
+ <li><a href="#basic_ops_modify_topic">Modifying topics</a>
+ <li><a href="#basic_ops_restarting">Graceful shutdown</a>
+ <li><a href="#basic_ops_leader_balancing">Balancing leadership</a>
+ <li><a href="#basic_ops_consumer_lag">Checking consumer position</a>
+ <li><a href="#basic_ops_mirror_maker">Mirroring data between clusters</a>
+ <li><a href="#basic_ops_cluster_expansion">Expanding your cluster</a>
+ <li><a href="#basic_ops_decommissioning_brokers">Decommissioning brokers</a>
+ <li><a href="#basic_ops_increase_replication_factor">Increasing replication factor</a>
+ </ul>
+ <li><a href="#datacenters">6.2 Datacenters</a>
+ <li><a href="#config">6.3 Important Configs</a>
+ <ul>
+ <li><a href="#serverconfig">Important Server Configs</a>
+ <li><a href="#clientconfig">Important Client Configs</a>
+ <li><a href="#prodconfig">A Production Server Configs</a>
+ </ul>
+ <li><a href="#java">6.4 Java Version</a>
+ <li><a href="#hwandos">6.5 Hardware and OS</a>
+ <ul>
+ <li><a href="#os">OS</a>
+ <li><a href="#diskandfs">Disks and Filesystems</a>
+ <li><a href="#appvsosflush">Application vs OS Flush Management</a>
+ <li><a href="#linuxflush">Linux Flush Behavior</a>
+ <li><a href="#ext4">Ext4 Notes</a>
+ </ul>
+ <li><a href="#monitoring">6.6 Monitoring</a>
+ <li><a href="#zk">6.7 ZooKeeper</a>
+ <ul>
+ <li><a href="#zkversion">Stable Version</a>
+ <li><a href="#zkops">Operationalization</a>
+ </ul>
+ </ul>
+ </li>
+ <li><a href="#security">7. Security</a>
+ <ul>
+ <li><a href="#security_overview">7.1 Security Overview</a></li>
+ <li><a href="#security_ssl">7.2 Encryption and Authentication using SSL</a></li>
+ <li><a href="#security_sasl">7.3 Authentication using SASL</a></li>
+ <li><a href="#security_authz">7.4 Authorization and ACLs</a></li>
+ <li><a href="#zk_authz">7.5 ZooKeeper Authentication</a></li>
<ul>
- <li><a href="#zkversion">Stable Version</a>
- <li><a href="#zkops">Operationalization</a>
+ <li><a href="#zk_authz_new">New Clusters</a></li>
+ <li><a href="#zk_authz_migration">Migrating Clusters</a></li>
+ <li><a href="#zk_authz_ensemble">Migrating the ZooKeeper Ensemble</a></li>
</ul>
- </ul>
- </li>
- <li><a href="#security">7. Security</a>
- <ul>
- <li><a href="#security_overview">7.1 Security Overview</a></li>
- <li><a href="#security_ssl">7.2 Encryption and Authentication using SSL</a></li>
- <li><a href="#security_sasl">7.3 Authentication using SASL</a></li>
- <li><a href="#security_authz">7.4 Authorization and ACLs</a></li>
- <li><a href="#zk_authz">7.5 ZooKeeper Authentication</a></li>
+ </ul>
+ </li>
+ <li><a href="#connect">8. Kafka Connect</a>
<ul>
- <li><a href="#zk_authz_new">New Clusters</a></li>
- <li><a href="#zk_authz_migration">Migrating Clusters</a></li>
- <li><a href="#zk_authz_ensemble">Migrating the ZooKeeper Ensemble</a></li>
+ <li><a href="#connect_overview">8.1 Overview</a></li>
+ <li><a href="#connect_user">8.2 User Guide</a></li>
+ <li><a href="#connect_development">8.3 Connector Development Guide</a></li>
</ul>
- </ul>
- </li>
- <li><a href="#connect">8. Kafka Connect</a>
- <ul>
- <li><a href="#connect_overview">8.1 Overview</a></li>
- <li><a href="#connect_user">8.2 User Guide</a></li>
- <li><a href="#connect_development">8.3 Connector Development Guide</a></li>
- </ul>
- </li>
-</ul>
+ </li>
+ </ul>
-<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="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" href="#api">2. API</a></h2>
+ <h2><a id="api" href="#api">2. API</a></h2>
-<!--#include virtual="api.html" -->
+ <!--#include virtual="api.html" -->
-<h2><a id="configuration" href="#configuration">3. Configuration</a></h2>
+ <h2><a id="configuration" href="#configuration">3. Configuration</a></h2>
-<!--#include virtual="configuration.html" -->
+ <!--#include virtual="configuration.html" -->
-<h2><a id="design" href="#design">4. Design</a></h2>
+ <h2><a id="design" href="#design">4. Design</a></h2>
-<!--#include virtual="design.html" -->
+ <!--#include virtual="design.html" -->
-<h2><a id="implementation" href="#implementation">5. Implementation</a></h2>
+ <h2><a id="implementation" href="#implementation">5. Implementation</a></h2>
-<!--#include virtual="implementation.html" -->
+ <!--#include virtual="implementation.html" -->
-<h2><a id="operations" href="#operations">6. Operations</a></h2>
+ <h2><a id="operations" href="#operations">6. Operations</a></h2>
-<!--#include virtual="ops.html" -->
+ <!--#include virtual="ops.html" -->
-<h2><a id="security" href="#security">7. Security</a></h2>
-<!--#include virtual="security.html" -->
+ <h2><a id="security" href="#security">7. Security</a></h2>
+ <!--#include virtual="security.html" -->
-<h2><a id="connect" href="#connect">8. Kafka Connect</a></h2>
-<!--#include virtual="connect.html" -->
+ <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/1b8cdf48/code.html
----------------------------------------------------------------------
diff --git a/code.html b/code.html
index 4e3884c..812de9f 100644
--- a/code.html
+++ b/code.html
@@ -1,22 +1,31 @@
<!--#include virtual="includes/header.html" -->
-<h1>Getting the code</h1>
-<p>
-Our code is kept in git. You can check it out like this:
-</p>
-<pre>
- git clone https://git-wip-us.apache.org/repos/asf/kafka.git kafka
-</pre>
-<p>
-Information on contributing patches can be found <a href="contributing.html">here</a>.
-</p>
-<p>
-Official releases are available <a href="downloads.html">here</a>.
-</p>
-<p>
-The source code for the web site and documentation is kept <a href="http://svn.apache.org/repos/asf/kafka/site">here</a>. We think documentation is a core part of the project and welcome any improvements, suggestions, or clarifications.
-</p>
-<p>
-To setup IDEs for development, following <a href="https://cwiki.apache.org/confluence/display/KAFKA/Developer+Setup">this guide</a> on the wiki.
-</p>
+<!--#include virtual="includes/top.html" -->
+<div class="content">
+ <!--#include virtual="includes/nav.html" -->
+ <div class="right">
+ <h1>Getting the code</h1>
+ <p>
+ Our code is kept in git. You can check it out like this:
+ </p>
+ <pre>
+ git clone https://git-wip-us.apache.org/repos/asf/kafka.git kafka
+ </pre>
+ <p>
+ Information on contributing patches can be found <a href="contributing.html">here</a>.
+ </p>
+ <p>
+ Official releases are available <a href="downloads.html">here</a>.
+ </p>
+ <p>
+ The source code for the web site and documentation is kept <a href="http://svn.apache.org/repos/asf/kafka/site">here</a>. We think documentation is a core part of the project and welcome any improvements, suggestions, or clarifications.
+ </p>
+ <p>
+ To setup IDEs for development, following <a href="https://cwiki.apache.org/confluence/display/KAFKA/Developer+Setup">this guide</a> on the wiki.
+ </p>
+
+ <script>
+ // Show selected style on nav item
+ $(function() { $('.b-nav__project').addClass('selected'); });
+ </script>
<!--#include virtual="includes/footer.html" -->
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/1b8cdf48/coding-guide.html
----------------------------------------------------------------------
diff --git a/coding-guide.html b/coding-guide.html
index ebc6a46..c94a0eb 100644
--- a/coding-guide.html
+++ b/coding-guide.html
@@ -1,103 +1,110 @@
<!--#include virtual="includes/header.html" -->
+<!--#include virtual="includes/top.html" -->
+<div class="content">
+ <!--#include virtual="includes/nav.html" -->
+ <div class="right">
+ <h1>Coding guidelines</h1>
+ <p>
+ These guidelines are meant to encourage consistency and best practices amongst people working on the Kafka code base. They should be observed unless there is a compelling reason to ignore them.
+ </p>
-<h1>Coding Guidelines</h1>
+ <h2>Basic Stuff</h2>
+ <ul>
+ <li>Avoid cryptic abbreviations. Single letter variable names are fine in very short methods with few variables, otherwise make them informative.</li>
+ <li>Clear code is preferable to comments. When possible make your naming so good you don't need comments. When that isn't possible comments should be thought of as mandatory, write them to be <i>read</i>.</li>
+ <li>Logging, configuration, and public APIs are our "UI". Make them pretty, consistent, and usable.</li>
+ <li>There is not a maximum line length (certainly not 80 characters, we don't work on punch cards any more), but be reasonable.</li>
+ <li>Don't be sloppy. Don't check in commented out code: we use version control, it is still there in the history. Don't leave TODOs in the code or FIXMEs if you can help it. Don't leave println statements in the code. Hopefully this is all obvious.</li>
+ <li>We want people to use our stuff, which means we need clear, correct documentation. User documentation should be considered a part of any user-facing the feature, just like unit tests or performance results.</li>
+ <li>Don't duplicate code (duh).</li>
+ <li>Kafka is system software, and certain things are appropriate in system software that are not appropriate elsewhere. Sockets, bytes, concurrency, and distribution are our core competency which means we will have a more "from scratch" implementation of some of these things then would be appropriate for software elsewhere in the stack. This is because we need to be exceptionally good at these things. This does not excuse fiddly low-level code, but it does excuse spending a little extra time to make sure that our filesystem structures, networking code, threading model, are all done perfectly right for our application rather than just trying to glue together ill-fitting off-the-shelf pieces (well-fitting off-the-shelf pieces are great though).</li>
+ </ul>
-<p>
-These guidelines are meant to encourage consistency and best practices amongst people working on the Kafka code base. They should be observed unless there is a compelling reason to ignore them.
-</p>
+ <h2>Scala</h2>
+ We are following the style guide given <a href="http://docs.scala-lang.org/style/">here</a> (though not perfectly). Below are some specifics worth noting:
+ <ul>
+ <li>Scala is a very flexible language. Use restraint. Magic cryptic one-liners do not impress us, readability impresses us.</li>
+ <li>Use <code>val</code>s when possible.</li>
+ <li>Use private when possible for member variables.</li>
+ <li>Method and member variable names should be in camel case with an initial lower case character like <code>aMethodName</code>.</li>
+ <li>Constants should be camel case with an initial capital <code>LikeThis</code> not <code>LIKE_THIS</code>.</li>
+ <li>Prefer a single top-level class per file for ease of finding things.</li>
+ <li>Do not use semi-colons unless required.</li>
+ <li>Avoid getters and setters - stick to plain <code>val</code>s or <code>var</code>s instead. If (later on) you require a custom setter (or getter) for a <code>var</code> named <code>myVar</code> then add a shadow <code>var myVar_underlying</code> and override the setter (<code>def myVar_=</code>) and the getter (<code>def myVar = myVar_underlying</code>).</li>
+ <li>Prefer <code>Option</code> to <code>null</code> in scala APIs.</li>
+ <li>Use named arguments when passing in literal values if the meaning is at all unclear, for example instead of <code>Utils.delete(true)</code> prefer <code>Utils.delete(recursive=true)</code>.
+ <li>Indentation is 2 spaces and never tabs. One could argue the right amount of indentation, but 2 seems to be standard for scala and consistency is best here since there is clearly no "right" way.</li>
+ <li>Include the optional parenthesis on a no-arg method only if the method has a side-effect, otherwise omit them. For example <code>fileChannel.force()</code> and <code>fileChannel.size</code>. This helps emphasize that you are calling the method for the side effect, which is changing some state, not just getting the return value.</li>
+ <li>Prefer case classes to tuples in important APIs to make it clear what the intended contents are.</li>
+ </ul>
-<h2>Basic Stuff</h2>
-<ul>
-<li>Avoid cryptic abbreviations. Single letter variable names are fine in very short methods with few variables, otherwise make them informative.</li>
-<li>Clear code is preferable to comments. When possible make your naming so good you don't need comments. When that isn't possible comments should be thought of as mandatory, write them to be <i>read</i>.</li>
-<li>Logging, configuration, and public APIs are our "UI". Make them pretty, consistent, and usable.</li>
-<li>There is not a maximum line length (certainly not 80 characters, we don't work on punch cards any more), but be reasonable.</li>
-<li>Don't be sloppy. Don't check in commented out code: we use version control, it is still there in the history. Don't leave TODOs in the code or FIXMEs if you can help it. Don't leave println statements in the code. Hopefully this is all obvious.</li>
-<li>We want people to use our stuff, which means we need clear, correct documentation. User documentation should be considered a part of any user-facing the feature, just like unit tests or performance results.</li>
-<li>Don't duplicate code (duh).</li>
-<li>Kafka is system software, and certain things are appropriate in system software that are not appropriate elsewhere. Sockets, bytes, concurrency, and distribution are our core competency which means we will have a more "from scratch" implementation of some of these things then would be appropriate for software elsewhere in the stack. This is because we need to be exceptionally good at these things. This does not excuse fiddly low-level code, but it does excuse spending a little extra time to make sure that our filesystem structures, networking code, threading model, are all done perfectly right for our application rather than just trying to glue together ill-fitting off-the-shelf pieces (well-fitting off-the-shelf pieces are great though).</li>
-</ul>
+ <h2>Logging</h2>
+ <ul>
+ <li>Logging is one third of our "UI" and it should be taken seriously. Please take the time to assess the logs when making a change to ensure that the important things are getting logged and there is no junk there.</li>
+ <li>Logging statements should be complete sentences with proper capitalization that are written to be read by a person not necessarily familiar with the source code. It is fine to put in hacky little logging statements when debugging, but either clean them up or remove them before checking in. So logging something like "INFO: entering SyncProducer send()" is not appropriate.</li>
+ <li>Logging should not mention class names or internal variables.</li>
+ <li>There are six levels of logging <code>TRACE</code>, <code>DEBUG</code>, <code>INFO</code>, <code>WARN</code>, <code>ERROR</code>, and <code>FATAL</code>, they should be used as follows.
+ <ul>
+ <li><code>INFO</code> is the level you should assume the software will be run in. INFO messages are things which are not bad but which the user will definitely want to know about every time they occur.
+ <li><code>TRACE</code> and <code>DEBUG</code> are both things you turn on when something is wrong and you want to figure out what is going on. <code>DEBUG</code> should not be so fine grained that it will seriously effect the performance of the server. <code>TRACE</code> can be anything. Both <code>DEBUG</code> and <code>TRACE</code> statements should be wrapped in an <code>if(logger.isDebugEnabled)</code> check to avoid pasting together big strings all the time.
+ <li><code>WARN</code> and <code>ERROR</code> indicate something that is bad. Use <code>WARN</code> if you aren't totally sure it is bad, and <code>ERROR</code> if you are.
+ <li>Use <code>FATAL</code> only right before calling <code>System.exit()</code>.
+ </ul>
+ </li>
+ </ul>
-<h2>Scala</h2>
-We are following the style guide given <a href="http://docs.scala-lang.org/style/">here</a> (though not perfectly). Below are some specifics worth noting:
-<ul>
-<li>Scala is a very flexible language. Use restraint. Magic cryptic one-liners do not impress us, readability impresses us.</li>
-<li>Use <code>val</code>s when possible.</li>
-<li>Use private when possible for member variables.</li>
-<li>Method and member variable names should be in camel case with an initial lower case character like <code>aMethodName</code>.</li>
-<li>Constants should be camel case with an initial capital <code>LikeThis</code> not <code>LIKE_THIS</code>.</li>
-<li>Prefer a single top-level class per file for ease of finding things.</li>
-<li>Do not use semi-colons unless required.</li>
-<li>Avoid getters and setters - stick to plain <code>val</code>s or <code>var</code>s instead. If (later on) you require a custom setter (or getter) for a <code>var</code> named <code>myVar</code> then add a shadow <code>var myVar_underlying</code> and override the setter (<code>def myVar_=</code>) and the getter (<code>def myVar = myVar_underlying</code>).</li>
-<li>Prefer <code>Option</code> to <code>null</code> in scala APIs.</li>
-<li>Use named arguments when passing in literal values if the meaning is at all unclear, for example instead of <code>Utils.delete(true)</code> prefer <code>Utils.delete(recursive=true)</code>.
-<li>Indentation is 2 spaces and never tabs. One could argue the right amount of indentation, but 2 seems to be standard for scala and consistency is best here since there is clearly no "right" way.</li>
-<li>Include the optional parenthesis on a no-arg method only if the method has a side-effect, otherwise omit them. For example <code>fileChannel.force()</code> and <code>fileChannel.size</code>. This helps emphasize that you are calling the method for the side effect, which is changing some state, not just getting the return value.</li>
-<li>Prefer case classes to tuples in important APIs to make it clear what the intended contents are.</li>
-</ul>
+ <h2>Monitoring</h2>
+ <ul>
+ <li>Monitoring is the second third of our "UI" and it should also be taken seriously.</li>
+ <li>We use JMX for monitoring.</li>
+ <li>Any new features should come with appropriate monitoring to know the feature is working correctly. This is at least as important as unit tests as it verifies production.</li>
+ </ul>
-<h2>Logging</h2>
-<ul>
-<li>Logging is one third of our "UI" and it should be taken seriously. Please take the time to assess the logs when making a change to ensure that the important things are getting logged and there is no junk there.</li>
-<li>Logging statements should be complete sentences with proper capitalization that are written to be read by a person not necessarily familiar with the source code. It is fine to put in hacky little logging statements when debugging, but either clean them up or remove them before checking in. So logging something like "INFO: entering SyncProducer send()" is not appropriate.</li>
-<li>Logging should not mention class names or internal variables.</li>
-<li>There are six levels of logging <code>TRACE</code>, <code>DEBUG</code>, <code>INFO</code>, <code>WARN</code>, <code>ERROR</code>, and <code>FATAL</code>, they should be used as follows.
- <ul>
- <li><code>INFO</code> is the level you should assume the software will be run in. INFO messages are things which are not bad but which the user will definitely want to know about every time they occur.
- <li><code>TRACE</code> and <code>DEBUG</code> are both things you turn on when something is wrong and you want to figure out what is going on. <code>DEBUG</code> should not be so fine grained that it will seriously effect the performance of the server. <code>TRACE</code> can be anything. Both <code>DEBUG</code> and <code>TRACE</code> statements should be wrapped in an <code>if(logger.isDebugEnabled)</code> check to avoid pasting together big strings all the time.
- <li><code>WARN</code> and <code>ERROR</code> indicate something that is bad. Use <code>WARN</code> if you aren't totally sure it is bad, and <code>ERROR</code> if you are.
- <li>Use <code>FATAL</code> only right before calling <code>System.exit()</code>.
- </ul>
-</li>
-</ul>
+ <h2>Unit Tests</h2>
+ <ul>
+ <li>New patches should come with unit tests that verify the functionality being added.</li>
+ <li>Unit tests are first rate code, and should be treated like it. They should not contain code duplication, cryptic hackery, or anything like that.</li>
+ <li>Be aware of the methods in <code>kafka.utils.TestUtils</code>, they make a lot of the below things easier to get right.</li>
+ <li>Unit tests should test the least amount of code possible, don't start the whole server unless there is no other way to test a single class or small group of classes in isolation.</li>
+ <li>Tests should not depend on any external resources, they need to set up and tear down their own stuff. This means if you want zookeeper it needs to be started and stopped, you can't depend on it already being there. Likewise if you need a file with some data in it, you need to write it in the beginning of the test and delete it (pass or fail).</li>
+ <li>It is okay to use the filesystem and network in tests since that is our business but you need to clean up after yourself. There are helpers for this in <code>TestUtils</code>.</li>
+ <li>Do not use sleep or other timing assumptions in tests, it is always, always, always wrong and will fail intermittently on any test server with other things going on that causes delays. Write tests in such a way that they are not timing dependent. Seriously. One thing that will help this is to never directly use the system clock in code (i.e. <code>System.currentTimeMillis</code>) but instead to use the <code>kafka.utils.Time</code>. This is a trait that has a mock implementation allowing you to programmatically and deterministically cause the passage of time when you inject this mock clock instead of the system clock.</li>
+ <li>It must be possible to run the tests in parallel, without having them collide. This is a practical thing to allow multiple branches to CI on a single CI server. This means you can't hard code directories or ports or things like that in tests because two instances will step on each other. Again <code>TestUtils</code> has helpers for this stuff (e.g. <code>TestUtils.choosePort</code> will find a free port for you).</li>
+ </ul>
-<h2>Monitoring</h2>
-<ul>
-<li>Monitoring is the second third of our "UI" and it should also be taken seriously.</li>
-<li>We use JMX for monitoring.</li>
-<li>Any new features should come with appropriate monitoring to know the feature is working correctly. This is at least as important as unit tests as it verifies production.</li>
-</ul>
+ <h2>Configuration</h2>
+ <ul>
+ <li>Configuration is the final third of our "UI".</li>
+ <li>Names should be thought through from the point of view of the person using the config, but often programmers choose configuration names that make sense for someone reading the code.</li>
+ <li>Often the value that makes most sense in configuration is <i>not</i> the one most useful to program with. For example, let's say you want to throttle I/O to avoid using up all the I/O bandwidth. The easiest thing to implement is to give a "sleep time" configuration that let's the program sleep after doing I/O to throttle down its rate. But notice how hard it is to correctly use this configuration parameter, the user has to figure out the rate of I/O on the machine, and then do a bunch of arithmetic to calculate the right sleep time to give the desired rate of I/O on the system. It is much, much, much better to just have the user configure the maximum I/O rate they want to allow (say 5MB/sec) and then calculate the appropriate sleep time from that and the actual I/O rate. Another way to say this is that configuration should always be in terms of the quantity that the user knows, not the quantity you want to use.</li>
+ <li>Configuration is the answer to problems we can't solve up front for some reason--if there is a way to just choose a best value do that instead.</li>
+ <li>Configuration should come from the instance-level properties file. No additional sources of config (environment variables, system properties, etc) should be added as these usually inhibit running multiple instances of a broker on one machine.</li>
+ </ul>
-<h2>Unit Tests</h2>
-<ul>
-<li>New patches should come with unit tests that verify the functionality being added.</li>
-<li>Unit tests are first rate code, and should be treated like it. They should not contain code duplication, cryptic hackery, or anything like that.</li>
-<li>Be aware of the methods in <code>kafka.utils.TestUtils</code>, they make a lot of the below things easier to get right.</li>
-<li>Unit tests should test the least amount of code possible, don't start the whole server unless there is no other way to test a single class or small group of classes in isolation.</li>
-<li>Tests should not depend on any external resources, they need to set up and tear down their own stuff. This means if you want zookeeper it needs to be started and stopped, you can't depend on it already being there. Likewise if you need a file with some data in it, you need to write it in the beginning of the test and delete it (pass or fail).</li>
-<li>It is okay to use the filesystem and network in tests since that is our business but you need to clean up after yourself. There are helpers for this in <code>TestUtils</code>.</li>
-<li>Do not use sleep or other timing assumptions in tests, it is always, always, always wrong and will fail intermittently on any test server with other things going on that causes delays. Write tests in such a way that they are not timing dependent. Seriously. One thing that will help this is to never directly use the system clock in code (i.e. <code>System.currentTimeMillis</code>) but instead to use the <code>kafka.utils.Time</code>. This is a trait that has a mock implementation allowing you to programmatically and deterministically cause the passage of time when you inject this mock clock instead of the system clock.</li>
-<li>It must be possible to run the tests in parallel, without having them collide. This is a practical thing to allow multiple branches to CI on a single CI server. This means you can't hard code directories or ports or things like that in tests because two instances will step on each other. Again <code>TestUtils</code> has helpers for this stuff (e.g. <code>TestUtils.choosePort</code> will find a free port for you).</li>
-</ul>
+ <h2>Concurrency</h2>
+ <ul>
+ <li>Encapsulate synchronization. That is, locks should be private member variables within a class and only one class or method should need to be examined to verify the correctness of the synchronization strategy.</li>
+ <li>Annotate things as <code>@threadsafe</code> when they are supposed to be and <code>@notthreadsafe</code> when they aren't to help track this stuff.</li>
+ <li>There are a number of gotchas with threads and threadpools: is the daemon flag set appropriately for your threads? are your threads being named in a way that will distinguish their purpose in a thread dump? What happens when the number of queued tasks hits the limit (do you drop stuff? do you block?).</li>
+ <li>Prefer the java.util.concurrent packages to either low-level wait-notify, custom locking/synchronization, or higher level scala-specific primitives. The util.concurrent stuff is well thought out and actually works correctly. There is a generally feeling that threads and locking are not going to be the concurrency primitives of the future because of a variety of well-known weaknesses they have. This is probably true, but they have the advantage of actually being mature enough to use for high-performance software <i>right now</i>; their well-known deficiencies are easily worked around by equally well known best-practices. So avoid actors, software transactional memory, tuple spaces, or anything else not written by Doug Lea and used by at least a million other productions systems. :-)</li>
+ </ul>
-<h2>Configuration</h2>
-<ul>
-<li>Configuration is the final third of our "UI".</li>
-<li>Names should be thought through from the point of view of the person using the config, but often programmers choose configuration names that make sense for someone reading the code.</li>
-<li>Often the value that makes most sense in configuration is <i>not</i> the one most useful to program with. For example, let's say you want to throttle I/O to avoid using up all the I/O bandwidth. The easiest thing to implement is to give a "sleep time" configuration that let's the program sleep after doing I/O to throttle down its rate. But notice how hard it is to correctly use this configuration parameter, the user has to figure out the rate of I/O on the machine, and then do a bunch of arithmetic to calculate the right sleep time to give the desired rate of I/O on the system. It is much, much, much better to just have the user configure the maximum I/O rate they want to allow (say 5MB/sec) and then calculate the appropriate sleep time from that and the actual I/O rate. Another way to say this is that configuration should always be in terms of the quantity that the user knows, not the quantity you want to use.</li>
-<li>Configuration is the answer to problems we can't solve up front for some reason--if there is a way to just choose a best value do that instead.</li>
-<li>Configuration should come from the instance-level properties file. No additional sources of config (environment variables, system properties, etc) should be added as these usually inhibit running multiple instances of a broker on one machine.</li>
-</ul>
+ <h2>Backwards Compatibility</h2>
+ <ul>
+ <li>Our policy is that the Kafka protocols and data formats should support backwards compatibility for one release to enable no-downtime upgrades (unless there is a <i>very</i> compelling counter-argument). This means the server MUST be able to support requests from both old and new clients simultaneously. This compatability need only be retained for one release (e.g. 0.7 must accept requests from 0.6 clients, but this need not be maintained indefinitely). The code handling the "old" path can be removed in the next release or whenever we can get all the clients up-to-date. A typical upgrade sequence for binary format changes would be (1) upgrade consumers to handle new message format, (2) upgrade server, (3) clients.</li>
+ <li>There are three things which require this binary compatibility: request objects, persistent data structure (messages and message sets), and zookeeper structures and protocols. The message binary structure has a "magic" byte to allow it to be evolved, this number should be incremented when the format is changed and the number can be checked to apply the right logic and fill in defaults appropriately. Network requests have a request id which serve a similar purpose, any change to a request object must be accompanied by a change in the request id. Any change here should be accompanied by compatibility tests that save requests or messages in the old format as a binary file which is tested for compatibility with the new code.</li>
+ </ul>
-<h2>Concurrency</h2>
-<ul>
-<li>Encapsulate synchronization. That is, locks should be private member variables within a class and only one class or method should need to be examined to verify the correctness of the synchronization strategy.</li>
-<li>Annotate things as <code>@threadsafe</code> when they are supposed to be and <code>@notthreadsafe</code> when they aren't to help track this stuff.</li>
-<li>There are a number of gotchas with threads and threadpools: is the daemon flag set appropriately for your threads? are your threads being named in a way that will distinguish their purpose in a thread dump? What happens when the number of queued tasks hits the limit (do you drop stuff? do you block?).</li>
-<li>Prefer the java.util.concurrent packages to either low-level wait-notify, custom locking/synchronization, or higher level scala-specific primitives. The util.concurrent stuff is well thought out and actually works correctly. There is a generally feeling that threads and locking are not going to be the concurrency primitives of the future because of a variety of well-known weaknesses they have. This is probably true, but they have the advantage of actually being mature enough to use for high-performance software <i>right now</i>; their well-known deficiencies are easily worked around by equally well known best-practices. So avoid actors, software transactional memory, tuple spaces, or anything else not written by Doug Lea and used by at least a million other productions systems. :-)</li>
-</ul>
+ <h2>Client Code</h2>
+ <p>There are a few things that need to be considered in client code that are not a major concern on the server side.</p>
+ <ul>
+ <li>Libraries needed by the client should be avoided whenever possible. Clients are run in someone else's code and it is very possible that they may have the same library we have, but a different and incompatible version. This will mean they can't use our client. For this reason the client should not use any libraries that are not strictly necessary.</li>
+ <li>We should attempt to maintain API compatibility when possible, though at this point in the project's lifecycle it is more important to make things good rather than avoid breakage.</li>
+ </ul>
-<h2>Backwards Compatibility</h2>
-<ul>
-<li>Our policy is that the Kafka protocols and data formats should support backwards compatibility for one release to enable no-downtime upgrades (unless there is a <i>very</i> compelling counter-argument). This means the server MUST be able to support requests from both old and new clients simultaneously. This compatability need only be retained for one release (e.g. 0.7 must accept requests from 0.6 clients, but this need not be maintained indefinitely). The code handling the "old" path can be removed in the next release or whenever we can get all the clients up-to-date. A typical upgrade sequence for binary format changes would be (1) upgrade consumers to handle new message format, (2) upgrade server, (3) clients.</li>
-<li>There are three things which require this binary compatibility: request objects, persistent data structure (messages and message sets), and zookeeper structures and protocols. The message binary structure has a "magic" byte to allow it to be evolved, this number should be incremented when the format is changed and the number can be checked to apply the right logic and fill in defaults appropriately. Network requests have a request id which serve a similar purpose, any change to a request object must be accompanied by a change in the request id. Any change here should be accompanied by compatibility tests that save requests or messages in the old format as a binary file which is tested for compatibility with the new code.</li>
-</ul>
-
-<h2>Client Code</h2>
-<p>There are a few things that need to be considered in client code that are not a major concern on the server side.</p>
-<ul>
- <li>Libraries needed by the client should be avoided whenever possible. Clients are run in someone else's code and it is very possible that they may have the same library we have, but a different and incompatible version. This will mean they can't use our client. For this reason the client should not use any libraries that are not strictly necessary.</li>
-<li>We should attempt to maintain API compatibility when possible, though at this point in the project's lifecycle it is more important to make things good rather than avoid breakage.</li>
-</ul>
+ <script>
+ // Show selected style on nav item
+ $(function() { $('.b-nav__project').addClass('selected'); });
+ </script>
<!--#include virtual="includes/footer.html" -->
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/1b8cdf48/committers.html
----------------------------------------------------------------------
diff --git a/committers.html b/committers.html
index 3ef95db..66e7155 100644
--- a/committers.html
+++ b/committers.html
@@ -1,159 +1,166 @@
<!--#include virtual="includes/header.html" -->
+<!--#include virtual="includes/top.html" -->
+<div class="content">
+ <!--#include virtual="includes/nav.html" -->
+ <div class="right">
+ <h1>The committers</h1>
+ <table style="margin-top: 4rem;">
+ <tr>
+ <td>
+ <img src="images/jun.jpg" width="150">
+ </td>
+ <td>
+ Jun Rao<br>
+ Committer, PMC member, and VP of Kafka<br>
+ <a href="http://www.linkedin.com/in/junrao">/in/junrao</a><br>
+ <a href="http://twitter.com/junrao">@junrao</a>
+ </td>
+ <td>
+ <img src="images/neha.jpg" width="150">
+ </td>
+ <td>
+ Neha Narkhede<br>
+ Committer, and PMC member<br>
+ <a href="http://www.linkedin.com/in/nehanarkhede">/in/nehanarkhede</a><br>
+ <a href="http://twitter.com/nehanarkhede">@nehanarkhede</a>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <img src="images/joe.jpg" width="150">
+ </td>
+ <td>
+ Joe Stein<br>
+ Committer, and PMC member<br>
+ <a href="http://www.linkedin.com/in/charmalloc">/in/charmalloc</a><br>
+ <a href="https://twitter.com/allthingshadoop">@allthingshadoop</a>
+ </td>
+ <td>
+ <img src="images/jay.jpg" height="150">
+ </td>
+ <td>
+ Jay Kreps<br>
+ Committer, and PMC member<br>
+ <a href="http://www.linkedin.com/in/jaykreps">/in/jaykreps</a><br>
+ <a href="http://twitter.com/jaykreps">@jaykreps</a>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <img src="images/joel.jpg" width="150">
+ </td>
+ <td>
+ Joel Koshy<br>
+ Committer, and PMC member<br>
+ <a href="http://www.linkedin.com/in/jjkoshy">/in/jjkoshy</a>
+ </td>
+ <td>
+ <img src="images/prashanth.jpg" width="150">
+ </td>
+ <td>
+ Prashanth Menon<br>
+ Committer, and PMC member<br>
+ <a href="http://ca.linkedin.com/in/prasmenon">/in/prasmenon</a><br>
+ <a href="https://twitter.com/prashanth_menon">twitter</a>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <img src="images/jakob.jpg" width="150">
+ </td>
+ <td>
+ Jakob Homan<br>
+ Apache Member, Committer, and PMC member<br>
+ <a href="http://www.linkedin.com/in/jghoman">/in/jghoman</a><br>
+ <a href="http://twitter.com/BlueBoxTraveler">@blueboxtraveler</a>
+ </td>
+ <td>
+ <img src="images/david.jpg" width="150">
+ </td>
+ <td>
+ David Arthur<br>
+ Committer<br>
+ <a href="http://www.linkedin.com/pub/david-arthur/8/245/b26">/in/davidarthur</a><br>
+ <a href="https://twitter.com/mumrah">@mumrah</a>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <img src="images/sriram.jpg" width="150">
+ </td>
+ <td>
+ Sriram Subramanian<br>
+ Committer<br>
+ <a href="http://www.linkedin.com/pub/sriram-subramanian/3/52a/162">/in/sriram</a><br>
+ <a href="http://twitter.com/sriramsub1">@sriramsub1</a>
+ </td>
+ <td>
+ <img src="images/guozhang.jpg" width="150">
+ </td>
+ <td>
+ Guozhang Wang<br>
+ Committer, and PMC member<br>
+ <a href="http://www.linkedin.com/in/guozhangwang">/in/guozhang</a><br>
+ <a href="https://twitter.com/guozhangwang">@guozhangwang</a>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <img src="images/gwenshap.jpg" width="150">
+ </td>
+ <td>
+ Gwen Shapira<br>
+ Committer<br>
+ <a href="https://www.linkedin.com/in/gwenshapira">/in/gwenshapira</a><br>
+ <a href="https://twitter.com/gwenshap">@gwenshap</a></br>
+ </td>
+ <td>
+ <img src="images/harsha.jpg" width="150">
+ </td>
+ <td>
+ Sriharsha Chintalapani<br>
+ Committer<br>
+ <a href="https://www.linkedin.com/in/sriharsha">/in/sriharsha</a><br>
+ <a href="https://twitter.com/d3fmacro">@d3fmacro</a></br>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <img src="images/ewencp.jpg" width="150">
+ </td>
+ <td>
+ Ewen Cheslack-Postava<br>
+ Committer<br>
+ <a href="https://www.linkedin.com/in/ewencp">/in/ewencp</a><br>
+ <a href="https://twitter.com/ewencp">@ewencp</a></br>
+ </td>
+ <td>
+ <img src="images/ijuma.jpg" width="150">
+ </td>
+ <td>
+ Ismael Juma<br>
+ Committer<br>
+ <a href="https://www.linkedin.com/in/ijuma">/in/ijuma</a><br>
+ <a href="https://twitter.com/ijuma">@ijuma</a></br>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ <img src="images/jason.jpg" width="150">
+ </td>
+ <td>
+ Jason Gustafson<br>
+ Committer<br>
+ <a href="https://www.linkedin.com/in/jasongustafson">/in/jasongustafson</a><br>
+ </td>
+ <td></td>
+ <td></td>
+ </tr>
+ </table>
-<h1>The Committers</h1>
-
-<table>
- <tr>
- <td>
- <img src="images/jun.jpg" width="150">
- </td>
- <td>
- Jun Rao<br>
- Committer, PMC member, and VP of Kafka<br>
- <a href="http://www.linkedin.com/in/junrao">/in/junrao</a><br>
- <a href="http://twitter.com/junrao">@junrao</a>
- </td>
- <td>
- <img src="images/neha.jpg" width="150">
- </td>
- <td>
- Neha Narkhede<br>
- Committer, and PMC member<br>
- <a href="http://www.linkedin.com/in/nehanarkhede">/in/nehanarkhede</a><br>
- <a href="http://twitter.com/nehanarkhede">@nehanarkhede</a>
- </td>
- </tr>
- <tr>
- <td>
- <img src="images/joe.jpg" width="150">
- </td>
- <td>
- Joe Stein<br>
- Committer, and PMC member<br>
- <a href="http://www.linkedin.com/in/charmalloc">/in/charmalloc</a><br>
- <a href="https://twitter.com/allthingshadoop">@allthingshadoop</a>
- </td>
- <td>
- <img src="images/jay.jpg" height="150">
- </td>
- <td>
- Jay Kreps<br>
- Committer, and PMC member<br>
- <a href="http://www.linkedin.com/in/jaykreps">/in/jaykreps</a><br>
- <a href="http://twitter.com/jaykreps">@jaykreps</a>
- </td>
- </tr>
- <tr>
- <td>
- <img src="images/joel.jpg" width="150">
- </td>
- <td>
- Joel Koshy<br>
- Committer, and PMC member<br>
- <a href="http://www.linkedin.com/in/jjkoshy">/in/jjkoshy</a>
- </td>
- <td>
- <img src="images/prashanth.jpg" width="150">
- </td>
- <td>
- Prashanth Menon<br>
- Committer, and PMC member<br>
- <a href="http://ca.linkedin.com/in/prasmenon">/in/prasmenon</a><br>
- <a href="https://twitter.com/prashanth_menon">twitter</a>
- </td>
- </tr>
- <tr>
- <td>
- <img src="images/jakob.jpg" width="150">
- </td>
- <td>
- Jakob Homan<br>
- Apache Member, Committer, and PMC member<br>
- <a href="http://www.linkedin.com/in/jghoman">/in/jghoman</a><br>
- <a href="http://twitter.com/BlueBoxTraveler">@blueboxtraveler</a>
- </td>
- <td>
- <img src="images/david.jpg" width="150">
- </td>
- <td>
- David Arthur<br>
- Committer<br>
- <a href="http://www.linkedin.com/pub/david-arthur/8/245/b26">/in/davidarthur</a><br>
- <a href="https://twitter.com/mumrah">@mumrah</a>
- </td>
- </tr>
- <tr>
- <td>
- <img src="images/sriram.jpg" width="150">
- </td>
- <td>
- Sriram Subramanian<br>
- Committer<br>
- <a href="http://www.linkedin.com/pub/sriram-subramanian/3/52a/162">/in/sriram</a><br>
- <a href="http://twitter.com/sriramsub1">@sriramsub1</a>
- </td>
- <td>
- <img src="images/guozhang.jpg" width="150">
- </td>
- <td>
- Guozhang Wang<br>
- Committer, and PMC member<br>
- <a href="http://www.linkedin.com/in/guozhangwang">/in/guozhang</a><br>
- <a href="https://twitter.com/guozhangwang">@guozhangwang</a>
- </td>
- </tr>
- <tr>
- <td>
- <img src="images/gwenshap.jpg" width="150">
- </td>
- <td>
- Gwen Shapira<br>
- Committer<br>
- <a href="https://www.linkedin.com/in/gwenshapira">/in/gwenshapira</a><br>
- <a href="https://twitter.com/gwenshap">@gwenshap</a></br>
- </td>
- <td>
- <img src="images/harsha.jpg" width="150">
- </td>
- <td>
- Sriharsha Chintalapani<br>
- Committer<br>
- <a href="https://www.linkedin.com/in/sriharsha">/in/sriharsha</a><br>
- <a href="https://twitter.com/d3fmacro">@d3fmacro</a></br>
- </td>
- </tr>
- <tr>
- <td>
- <img src="images/ewencp.jpg" width="150">
- </td>
- <td>
- Ewen Cheslack-Postava<br>
- Committer<br>
- <a href="https://www.linkedin.com/in/ewencp">/in/ewencp</a><br>
- <a href="https://twitter.com/ewencp">@ewencp</a></br>
- </td>
- <td>
- <img src="images/ijuma.jpg" width="150">
- </td>
- <td>
- Ismael Juma<br>
- Committer<br>
- <a href="https://www.linkedin.com/in/ijuma">/in/ijuma</a><br>
- <a href="https://twitter.com/ijuma">@ijuma</a></br>
- </td>
- </tr>
- <tr>
- <td>
- <img src="images/jason.jpg" width="150">
- </td>
- <td>
- Jason Gustafson<br>
- Committer<br>
- <a href="https://www.linkedin.com/in/jasongustafson">/in/jasongustafson</a><br>
- </td>
- <td></td>
- <td></td>
- </tr>
-</table>
+ <script>
+ // Show selected style on nav item
+ $(function() { $('.b-nav__project').addClass('selected'); });
+ </script>
<!--#include virtual="includes/footer.html" -->
http://git-wip-us.apache.org/repos/asf/kafka-site/blob/1b8cdf48/contact.html
----------------------------------------------------------------------
diff --git a/contact.html b/contact.html
index 3082407..c187937 100644
--- a/contact.html
+++ b/contact.html
@@ -1,37 +1,46 @@
<!--#include virtual="includes/header.html" -->
+<!--#include virtual="includes/top.html" -->
+<div class="content">
+ <!--#include virtual="includes/nav.html" -->
+ <div class="right">
+ <h1>Contact</h1>
+ <h3>Mailing Lists</h3>
-<h2>Mailing Lists</h2>
-
-<p>
-We have a few mailing lists hosted by Apache:
-</p>
-<ul>
- <li>
- <a href="mailto: users@kafka.apache.org">users@kafka.apache.org</a>: A list for general user questions about Kafka. To subscribe, send an email to <a href="mailto: users-subscribe@kafka.apache.org">users-subscribe@kafka.apache.org</a>. Archives are available <a href="http://mail-archives.apache.org/mod_mbox/kafka-users">here</a>.
- </li>
- <li>
- <a href="mailto: dev@kafka.apache.org">dev@kafka.apache.org</a>: A list for discussion on Kafka development. To subscribe, send an email to <a href="mailto: dev-subscribe@kafka.apache.org">dev-subscribe@kafka.apache.org</a>. Archives available <a href="http://mail-archives.apache.org/mod_mbox/kafka-dev">here</a>.
- </li>
- <li>
- <a href="mailto: commits@kafka.apache.org">commits@kafka.apache.org</a>: A list to track Kafka commits. To subscribe, send an email to <a href="mailto: commits-subscribe@kafka.apache.org">commits-subscribe@kafka.apache.org</a>. Archives available <a href="http://mail-archives.apache.org/mod_mbox/kafka-commits">here</a>.
- </li>
-</ul>
+ <p>
+ We have a few mailing lists hosted by Apache:
+ </p>
+ <ul>
+ <li>
+ <a href="mailto: users@kafka.apache.org">users@kafka.apache.org</a>: A list for general user questions about Kafka. To subscribe, send an email to <a href="mailto: users-subscribe@kafka.apache.org">users-subscribe@kafka.apache.org</a>. Archives are available <a href="http://mail-archives.apache.org/mod_mbox/kafka-users">here</a>.
+ </li>
+ <li>
+ <a href="mailto: dev@kafka.apache.org">dev@kafka.apache.org</a>: A list for discussion on Kafka development. To subscribe, send an email to <a href="mailto: dev-subscribe@kafka.apache.org">dev-subscribe@kafka.apache.org</a>. Archives available <a href="http://mail-archives.apache.org/mod_mbox/kafka-dev">here</a>.
+ </li>
+ <li>
+ <a href="mailto: commits@kafka.apache.org">commits@kafka.apache.org</a>: A list to track Kafka commits. To subscribe, send an email to <a href="mailto: commits-subscribe@kafka.apache.org">commits-subscribe@kafka.apache.org</a>. Archives available <a href="http://mail-archives.apache.org/mod_mbox/kafka-commits">here</a>.
+ </li>
+ </ul>
-<p>
-A searchable archive of the mailing list is available at <a href="http://search-hadoop.com/kafka">search-hadoop.com/kafka</a>.
-</p>
+ <p>
+ A searchable archive of the mailing list is available at <a href="http://search-hadoop.com/kafka">search-hadoop.com/kafka</a>.
+ </p>
-<p>
-To unsubscribe from any of these you just change the word "subscribe" in the above to "unsubscribe".
-</p>
+ <p>
+ To unsubscribe from any of these you just change the word "subscribe" in the above to "unsubscribe".
+ </p>
-<p>
-Prior to the move to Apache we had a Google group we used for discussion. Archives can be found <a href="http://groups.google.com/group/kafka-dev">here</a>. After that we were in Apache Incubator which has its own archives for <a href="http://mail-archives.apache.org/mod_mbox/incubator-kafka-users/">user</a>, <a href="http://mail-archives.apache.org/mod_mbox/incubator-kafka-dev/">dev</a>, and <a href="http://mail-archives.apache.org/mod_mbox/incubator-kafka-commits/">commit</a> lists.
-</p>
-
-<h2>IRC</h2>
-<p>
- We have an IRC channel where there is often a few people hanging around if you want an interactive discussion. You can find us on chat.freenode.net in #apache-kafka room (previously #kafka). The irc log can be found <a href="https://botbot.me/freenode/apache-kafka/">here</a>.
-</p>
+ <p>
+ Prior to the move to Apache we had a Google group we used for discussion. Archives can be found <a href="http://groups.google.com/group/kafka-dev">here</a>. After that we were in Apache Incubator which has its own archives for <a href="http://mail-archives.apache.org/mod_mbox/incubator-kafka-users/">user</a>, <a href="http://mail-archives.apache.org/mod_mbox/incubator-kafka-dev/">dev</a>, and <a href="http://mail-archives.apache.org/mod_mbox/incubator-kafka-commits/">commit</a> lists.
+ </p>
+ <h3>IRC</h3>
+ <p>
+ We have an IRC channel where there is often a few people hanging around if you want an interactive discussion. You can find us on chat.freenode.net in #apache-kafka room (previously #kafka). The irc log can be found <a href="https://botbot.me/freenode/apache-kafka/">here</a>.
+ </p>
+
+
+<script>
+// Show selected style on nav item
+$(function() { $('.b-nav__contact').addClass('selected'); });
+</script>
<!--#include virtual="includes/footer.html" -->