Back to blog

// OSSeva Blog

Migration

Apache Storm 2 End of Life: Upgrading from Storm 2.x to 3.x

Matt Reynolds6 min read

The short answer

Apache Storm 2.x is end of life. Storm 2.8.9, released on 22 July 2026, is the final 2.x release, and the project says there will be no further bug fixes, security patches or releases in the 2.x series. Apache Storm 3.0.0 shipped the same day, and 3.1.0 followed on 12 September 2026 with fixes for 17 CVEs, which the announcement tells 2.x users to treat as unpatched there. Storm 3 requires Java 25, and every Storm version still requires ZooKeeper.

What Apache Storm is, briefly

Apache Storm is an open source, distributed real-time computation system from the Apache Software Foundation. Batch processing with Hadoop MapReduce works on data at rest; Storm processes streaming data as it arrives. A stream is an unbounded sequence of tuples. Application logic is packaged into a topology, a graph of spouts and bolts: spouts read data streams from a source such as Apache Kafka, and bolts do the data processing. Unlike a MapReduce job, a topology runs until you kill it. Nimbus assigns work, supervisors run the workers on each node, and the Storm cluster coordinates through ZooKeeper. The setup guide makes a ZooKeeper cluster step one, and storm.zookeeper.servers is mandatory.

Typical use cases are real-time analytics, ETL and alerting on big data streams. Many teams now pick Apache Flink for new stream processing, but fault-tolerant Apache Storm topologies that have run for years are rarely rewritten just because a newer engine exists. That is why the 2.x end of life matters.

Storm versions and the ZooKeeper they bundle

ReleaseDateJavaZooKeeper client
Storm 2.4.025 Mar 2022Java 8+3.5.9
Storm 2.8.9 (final 2.x)22 Jul 2026Java 11+ (tested on 11, 17 and 21)3.9.5
Storm 3.0.022 Jul 2026Java 253.9.5
Storm 3.1.012 Sep 2026Java 253.9.5

The ZooKeeper column comes from the zookeeper.version property in each release's pom.xml. Storm 2.4.0 ships the ZooKeeper 3.5.9 client. The 3.5 line reached end of life on 1 June 2022, 3.5.9 still carries log4j 1.2.17, and CVE-2023-44981 has no fix for 3.5. Later releases moved to 3.9.5, which sits inside the affected range of the ZooKeeper advisories published on 16 September 2026 (fixed in 3.9.6). The ensemble your cluster points at has its own version, often older than the client jar. See Storm and ZooKeeper for how to check both.

Breaking changes in Storm 3.0.0

  • Java 25 is required. Workers run your topology code on that JVM, so this takes the most planning.
  • Clojure support is removed. The Clojure DSL and the storm-clojure module are gone. Topologies written against backtype.storm.clojure or org.apache.storm.clojure must be rewritten in Java first.
  • Two distributions. The lite package drops the optional Hadoop and Kafka integration jars; the full package is the drop-in choice.

The Java API stays backwards-compatible with Storm 2.x, so Java storm topologies should not need code changes. 3.0.0 also adds opt-in Zstd compression and a Y2038 fix for worker heartbeats.

Behaviour changes in Storm 3.1.0

3.1.0 is mainly a security release, and several fixes change defaults:

  • An unset nimbus.scheduler.strategy.class.whitelist now allows only the strategies shipped with Storm.
  • JSONP is off by default (ui.enable.jsonp).
  • The state serializer requires registered classes. The advisory warns that checkpoints written by an affected version may fail to restore.
  • nimbus.groups is now enforced even when nimbus.users is empty.
  • Clients that submit with storm jar --artifacts must be upgraded too.

CVE-2026-82434 exposed the topology ZooKeeper credential to read-only users and logs, so rotate storm.zookeeper.topology.auth.payload during the upgrade if you use ZooKeeper authentication.

A practical upgrade order

  1. Record what you run: the Storm version, the ZooKeeper jar and the ensemble version (commands below).
  2. Rewrite any Clojure topologies in Java while you are still on 2.x.
  3. Test every topology on Java 25 in staging.
  4. Go straight to 3.1.0 and set the changed defaults before cutover.
  5. Plan state migration for stateful topologies, given the serializer change.
  6. Upgrade clients alongside the cluster.
storm version
ls lib/ | grep -E '^zookeeper-[0-9]'
grep -A3 storm.zookeeper.servers conf/storm.yaml

If you cannot move yet

Java 25 on every worker host, and state that may not restore, are real reasons to stay on 2.x for a while. OSSeva's Apache Storm extended support ships patched, signed Storm 2.x builds today, and patches the ZooKeeper under them: OSSeva builds for ZooKeeper 3.4, 3.5, 3.6 and 3.7 are available now, with 3.8 and 3.9 support and VEX attestation for auditors. Start with Patch, or add Assure and Operate tiers. The Storm 2 end-of-life page has the dates, and you can talk to an engineer about the upgrade itself.

Frequently asked questions

Is Apache Storm 2 end of life?

Yes. Storm 2.8.9 (22 July 2026) is the final 2.x release. The branch is no longer maintained and gets no security fixes.

Does Storm 3 still need ZooKeeper?

Yes. The 3.1.0 setup guide says Storm uses ZooKeeper for coordinating the cluster, and storm.zookeeper.servers is required.

Which Java version does Storm 3 need?

Java 25, for both 3.0.0 and 3.1.0. The 2.8.9 docs list Java 11 or later, and the 2.4.0 docs Java 8 or later.

Do my Java topologies need code changes for Storm 3?

Usually not. The Java API is backwards-compatible; Clojure topologies must be rewritten.

Tags

Apache StormEnd of LifeZooKeeperUpgradeJava 25

Ready to get your open source under control?

Talk to an OSSeva engineer about CVE coverage, compliance, and migration support for your stack.