kafka-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From guozh...@apache.org
Subject [kafka] branch 1.0 updated: HOTFIX: Remove conflicts
Date Thu, 08 Feb 2018 17:54:51 GMT
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 <wangguoz@gmail.com>
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><b>For a rolling upgrade:</b></p>
-    <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
-        </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> 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>
-<p><b>Additional Upgrade Notes:</b></p>
-    <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>
-<h5><a id="upgrade_110_notable" href="#upgrade_110_notable">Notable changes in
-    <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
-    <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
-    <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>
-<h5><a id="upgrade_110_new_protocols" href="#upgrade_110_new_protocols">New Protocol
-<h5><a id="upgrade_110_streams" href="#upgrade_110_streams">Upgrading a 1.1.0
Kafka Streams Application</a></h5>
-    <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>
->>>>>>> 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

View raw message