This is an automated email from the ASF dual-hosted git repository.

guozhang pushed a commit to branch 1.0
in repository https://gitbox.apache.org/repos/asf/kafka.git


The following commit(s) were added to refs/heads/1.0 by this push:
     new e4ab3cd  HOTFIX: Remove conflicts
e4ab3cd is described below

commit e4ab3cd57e3269a57fa28e9bd3fc3425b9522197
Author: Guozhang Wang <[email protected]>
AuthorDate: Thu Feb 8 09:54:39 2018 -0800

    HOTFIX: Remove conflicts
---
 docs/upgrade.html | 71 -------------------------------------------------------
 1 file changed, 71 deletions(-)

diff --git a/docs/upgrade.html b/docs/upgrade.html
index 128cedb..ad665ad 100644
--- a/docs/upgrade.html
+++ b/docs/upgrade.html
@@ -19,77 +19,6 @@
 
 <script id="upgrade-template" type="text/x-handlebars-template">
 
-<<<<<<< HEAD
-=======
-<h4><a id="upgrade_1_1_0" href="#upgrade_1_1_0">Upgrading from 0.8.x, 0.9.x, 
0.10.0.x, 0.10.1.x, 0.10.2.x, 0.11.0.x or 1.0.x to 1.1.x</a></h4>
-<p>Kafka 1.1.0 introduces wire protocol changes. By following the recommended 
rolling upgrade plan below,
-    you guarantee no downtime during the upgrade. However, please review the 
<a href="#upgrade_110_notable">notable changes in 1.1.0</a> before upgrading.
-</p>
-
-<p><b>For a rolling upgrade:</b></p>
-
-<ol>
-    <li> Update server.properties on all brokers and add the following 
properties. CURRENT_KAFKA_VERSION refers to the version you
-        are upgrading from. CURRENT_MESSAGE_FORMAT_VERSION refers to the 
message format version currently in use. If you have previously
-        overridden the message format version, you should keep its current 
value. Alternatively, if you are upgrading from a version prior
-        to 0.11.0.x, then CURRENT_MESSAGE_FORMAT_VERSION should be set to 
match CURRENT_KAFKA_VERSION.
-        <ul>
-            <li>inter.broker.protocol.version=CURRENT_KAFKA_VERSION (e.g. 
0.8.2, 0.9.0, 0.10.0, 0.10.1, 0.10.2, 0.11.0, 1.0).</li>
-            <li>log.message.format.version=CURRENT_MESSAGE_FORMAT_VERSION  
(See <a href="#upgrade_10_performance_impact">potential performance impact
-                following the upgrade</a> for the details on what this 
configuration does.)</li>
-        </ul>
-        If you are upgrading from 0.11.0.x and you have not overridden the 
message format, then you only need to override
-        the inter-broker protocol format.
-        <ul>
-            <li>inter.broker.protocol.version=CURRENT_KAFKA_VERSION (e.g. 
0.8.2, 0.9.0, 0.10.0, 0.10.1, 0.10.2, 0.11.0, 1.0).</li>
-        </ul>
-    </li>
-    <li> Upgrade the brokers one at a time: shut down the broker, update the 
code, and restart it. </li>
-    <li> Once the entire cluster is upgraded, bump the protocol version by 
editing <code>inter.broker.protocol.version</code> and setting it to 1.1.
-    <li> Restart the brokers one by one for the new protocol version to take 
effect. </li>
-    <li> If you have overridden the message format version as instructed 
above, then you need to do one more rolling restart to
-        upgrade it to its latest version. Once all (or most) consumers have 
been upgraded to 0.11.0 or later,
-        change log.message.format.version to 1.1 on each broker and restart 
them one by one. Note that the older Scala consumer
-        does not support the new message format introduced in 0.11, so to 
avoid the performance cost of down-conversion (or to
-        take advantage of <a href="#upgrade_11_exactly_once_semantics">exactly 
once semantics</a>), the newer Java consumer must be used.</li>
-</ol>
-
-<p><b>Additional Upgrade Notes:</b></p>
-
-<ol>
-    <li>If you are willing to accept downtime, you can simply take all the 
brokers down, update the code and start them back up. They will start
-        with the new protocol by default.</li>
-    <li>Bumping the protocol version and restarting can be done any time after 
the brokers are upgraded. It does not have to be immediately after.
-        Similarly for the message format version.</li>
-    <li>If you are using Java8 method references in your Kafka Streams code 
you might need to update your code to resolve method ambiguties.
-        Hot-swaping the jar-file only might not work.</li>
-</ol>
-
-<h5><a id="upgrade_110_notable" href="#upgrade_110_notable">Notable changes in 
1.1.0</a></h5>
-<ul>
-    <li>The kafka artifact in Maven no longer depends on log4j or 
slf4j-log4j12. Similarly to the kafka-clients artifact, users
-        can now choose the logging back-end by including the appropriate slf4j 
module (slf4j-log4j12, logback, etc.). The release
-        tarball still includes log4j and slf4j-log4j12.</li>
-    <li><a href="https://cwiki.apache.org/confluence/x/uaBzB";>KIP-225</a> 
changed the metric "records.lag" to use tags for topic and partition. The 
original version with the name format "{topic}-{partition}.records-lag" is 
deprecated and will be removed in 2.0.0.</li>
-    <li>Kafka Streams is more robust against broker communication errors. 
Instead of stopping the Kafka Streams client with a fatal exception,
-       Kafka Streams tries to self-heal and reconnect to the cluster. Using 
the new <code>AdminClient</code> you have better control of how often
-       Kafka Streams retries and can <a 
href="/{{version}}/documentation/streams/developer-guide/config-streams">configure</a>
-       fine-grained timeouts (instead of hard coded retries as in older 
version).</li>
-    <li>Kafka Streams rebalance time was reduced further making Kafka Streams 
more responsive.</li>
-    <li>Kafka Connect now supports message headers in both sink and source 
connectors, and to manipulate them via simple message transforms. Connectors 
must be changed to explicitly use them. A new <code>HeaderConverter</code> is 
introduced to control how headers are (de)serialized, and the new 
"SimpleHeaderConverter" is used by default to use string representations of 
values.</li>
-</ul>
-
-<h5><a id="upgrade_110_new_protocols" href="#upgrade_110_new_protocols">New 
Protocol Versions</a></h5>
-<ul></ul>
-
-<h5><a id="upgrade_110_streams" href="#upgrade_110_streams">Upgrading a 1.1.0 
Kafka Streams Application</a></h5>
-<ul>
-    <li> Upgrading your Streams application from 1.0.0 to 1.1.0 does not 
require a broker upgrade.
-        A Kafka Streams 1.1.0 application can connect to 1.0, 0.11.0, 0.10.2 
and 0.10.1 brokers (it is not possible to connect to 0.10.0 brokers though). 
</li>
-    <li> See <a 
href="/{{version}}/documentation/streams/upgrade-guide#streams_api_changes_110">Streams
 API changes in 1.1.0</a> for more details. </li>
-</ul>
-
->>>>>>> 077fd9c... HOTFIX: Fix broken javadoc links on web docs(#4543)
 <h4><a id="upgrade_1_0_0" href="#upgrade_1_0_0">Upgrading from 0.8.x, 0.9.x, 
0.10.0.x, 0.10.1.x, 0.10.2.x or 0.11.0.x to 1.0.0</a></h4>
 <p>Kafka 1.0.0 introduces wire protocol changes. By following the recommended 
rolling upgrade plan below,
     you guarantee no downtime during the upgrade. However, please review the 
<a href="#upgrade_100_notable">notable changes in 1.0.0</a> before upgrading.

-- 
To stop receiving notification emails like this one, please contact
[email protected].

Reply via email to