This is an automated email from the ASF dual-hosted git repository. srdo pushed a commit to branch asf-site in repository https://gitbox.apache.org/repos/asf/storm-site.git
commit 661030e994b5633855ab859f637225ce34b494a7 Author: Stig Rohde Døssing <stigdoess...@gmail.com> AuthorDate: Thu May 30 23:04:20 2019 +0200 Fix some dead links and add parts to 2.0.0 release note about Java 8 and storm-core split, fix metrics v2 CsvStormReporter class name --- _posts/2019-05-30-storm200-released.md | 31 ++++++++++++++++++++++++++----- releases/1.2.2/metrics_v2.md | 2 +- releases/2.0.0-SNAPSHOT/metrics_v2.md | 2 +- 3 files changed, 28 insertions(+), 7 deletions(-) diff --git a/_posts/2019-05-30-storm200-released.md b/_posts/2019-05-30-storm200-released.md index 414a873..38f1264 100644 --- a/_posts/2019-05-30-storm200-released.md +++ b/_posts/2019-05-30-storm200-released.md @@ -34,20 +34,19 @@ For more details see [stateful windowing documentation](https://github.com/apach ### Removal of Storm-Kafka The most significant change to Storm's Kafka integration since 1.x, is that storm-kafka has been removed. The module was deprecated a while back, due to Kafka's deprecation of the underlying client library. Users will have to move to the storm-kafka-client module, which uses Kafka's ´kafka-clients´ library for integration. -For the most part, the migration to storm-kafka-client is straightforward. The documentation for storm-kafka-client contains a helpful mapping between the old and new spout configurations. If you are using any of the storm-kafka spouts, you will need to migrate offset checkpoints to the new spout, to avoid the new spout starting from scratch on your partitions. Storm provides a helper tool to do this which can be found [here](fhttps://github.com/apache/storm/tree/master/external/storm-ka [...] +For the most part, the migration to storm-kafka-client is straightforward. The documentation for storm-kafka-client contains a helpful mapping between the old and new spout configurations. If you are using any of the storm-kafka spouts, you will need to migrate offset checkpoints to the new spout, to avoid the new spout starting from scratch on your partitions. Storm provides a helper tool to do this which can be found [here](fhttps://github.com/apache/storm/tree/master/external/storm-ka [...] When performing a migration, you should stop your topology, run the migration tool, then redeploy your topology with the storm-kafka-client spout. ### Move to Using the KafkaConsumer.assign API -Storm-kafka-client in Storm 1.x allowed you to use Kafka's own mechanism to manage which spout tasks were responsible for which partitions. This mechanism was a poor fit for Storm, and was deprecated in 1.2.0. It has been [removed entirely in 2.0](https://issues.apache.org/jira/browse/STORM-2542.) +Storm-kafka-client in Storm 1.x allowed you to use Kafka's own mechanism to manage which spout tasks were responsible for which partitions. This mechanism was a poor fit for Storm, and was deprecated in 1.2.0. It has been [removed entirely in 2.0](https://issues.apache.org/jira/browse/STORM-2542). The storm-kafka-client Subscription interface has also been removed. It offered too limited control over the subscription behavior. It has been replaced with the TopicFilter and ManualPartitioner interfaces. Unless you were using a custom Subscription implementation, this will likely not -affect you. If you were using a custom Subscription, [the storm-kafka-client documentation describes how to customize assignment](https://github.com/apache/storm/blob/master/docs/storm-kafka-client.md#manual-partition-assigment-advanced) -. +affect you. If you were using a custom Subscription, [the storm-kafka-client documentation describes how to customize assignment](https://github.com/apache/storm/blob/master/docs/storm-kafka-client.md#manual-partition-assigment-advanced). ### Other Kafka Highlights -* The KafkaBolt now allows you to [specify a callback that will be called when a batch is written to Kafka](https://issues.apache.org/jira/browse/STORM-3175.) +* The KafkaBolt now allows you to [specify a callback that will be called when a batch is written to Kafka](https://issues.apache.org/jira/browse/STORM-3175). * The FirstPollOffsetStrategy behavior has been made consistent between the non-Trident and Trident spouts. It is now always the case that EARLIEST/LATEST only take effect on topology redeploy, and not when a worker restarts https://issues.apache.org/jira/browse/STORM-2990. * Storm-kafka-client now has a transactional non-opaque Trident spout https://issues.apache.org/jira/browse/STORM-2974. * There are new example modules for storm-kafka-client. You can find them [here](https://github.com/apache/storm/tree/master/examples/storm-kafka-client-examples). @@ -56,6 +55,28 @@ affect you. If you were using a custom Subscription, [the storm-kafka-client doc ## EOL for 1.0.x With the release of 2.0.0 the 1.0.x version line will no longer be maintained. 1.0.x users are strongly encouraged to upgrade to a more recent release. +## Move to Java 8 +Java 7 support has been dropped, and Storm 2.0.0 requires Java 8. + +## Reorganization of Storm Maven artifacts +The storm-core artifact has [been split](https://issues.apache.org/jira/browse/STORM-2441) into client and server-facing parts. Topology jars should depend on the following artifact as of Storm 2.0.0: + +``` +<groupId>org.apache.storm</groupId> +<artifactId>storm-client</artifactId> +<version>2.0.0</version> +<scope>provided</scope> +``` + +Projects using `LocalCluster` for testing will additionally need to depend on the Storm server jar: + +``` +<groupId>org.apache.storm</groupId> +<artifactId>storm-server</artifactId> +<version>2.0.0</version> +<scope>test</scope> +``` + ## Stay Tuned Keep an eye on the Apache Storm blog for additional posts by Storm contributors for more in-depth discussions of new features in Storm 2.0.0 including: diff --git a/releases/1.2.2/metrics_v2.md b/releases/1.2.2/metrics_v2.md index 761d3e6..7c77a1b 100644 --- a/releases/1.2.2/metrics_v2.md +++ b/releases/1.2.2/metrics_v2.md @@ -76,7 +76,7 @@ public class TupleCountingBolt extends BaseRichBolt { * Console Reporter (`org.apache.storm.metrics2.reporters.ConsoleStormReporter`): Reports metrics to `System.out`. - * CSV Reporter (`org.apache.storm.metrics2.reporters.CsvReporter`): + * CSV Reporter (`org.apache.storm.metrics2.reporters.CsvStormReporter`): Reports metrics to a CSV file. * Ganglia Reporter (`org.apache.storm.metrics2.reporters.GagliaStormReporter`): Reports metrics to a [Ganglia](http://ganglia.info) server. diff --git a/releases/2.0.0-SNAPSHOT/metrics_v2.md b/releases/2.0.0-SNAPSHOT/metrics_v2.md index e90ec76..63852e9 100644 --- a/releases/2.0.0-SNAPSHOT/metrics_v2.md +++ b/releases/2.0.0-SNAPSHOT/metrics_v2.md @@ -76,7 +76,7 @@ public class TupleCountingBolt extends BaseRichBolt { * Console Reporter (`org.apache.storm.metrics2.reporters.ConsoleStormReporter`): Reports metrics to `System.out`. - * CSV Reporter (`org.apache.storm.metrics2.reporters.CsvReporter`): + * CSV Reporter (`org.apache.storm.metrics2.reporters.CsvStormReporter`): Reports metrics to a CSV file. * Ganglia Reporter (`org.apache.storm.metrics2.reporters.GagliaStormReporter`): Reports metrics to a [Ganglia](http://ganglia.info) server.