This is an automated email from the ASF dual-hosted git repository.
github-actions[bot] pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/storm-site.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 834d6f4646 publishing 2026-08-23T20:15:47+00:00
834d6f4646 is described below
commit 834d6f4646b1ead52f644d7736c27e292b3418ff
Author: GitHub Actions Bot <>
AuthorDate: Sun Aug 23 20:15:47 2026 +0000
publishing 2026-08-23T20:15:47+00:00
---
Gemfile.lock | 2 +-
feed.xml | 4 ++--
releases/3.0.0/Cluster-State-Serialization.html | 11 +++++++++++
releases/3.0.0/Daemon-Fault-Tolerance.html | 4 +++-
releases/3.0.0/Lifecycle-of-a-topology.html | 6 +++++-
releases/current/Cluster-State-Serialization.html | 11 +++++++++++
releases/current/Daemon-Fault-Tolerance.html | 4 +++-
releases/current/Lifecycle-of-a-topology.html | 6 +++++-
8 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/Gemfile.lock b/Gemfile.lock
index f230180d1a..743c7f1f09 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -5,7 +5,7 @@ GEM
public_suffix (>= 2.0.2, < 8.0)
colorator (1.1.0)
concurrent-ruby (1.3.8)
- csv (3.3.5)
+ csv (3.3.6)
em-websocket (0.5.3)
eventmachine (>= 0.12.9)
http_parser.rb (~> 0)
diff --git a/feed.xml b/feed.xml
index 4eafb80452..cfc8ee32bf 100644
--- a/feed.xml
+++ b/feed.xml
@@ -5,8 +5,8 @@
<description>Apache Storm is a free and open source distributed realtime
computation system. Storm makes it easy to reliably process unbounded streams
of data, doing for realtime processing what Hadoop did for batch
processing.</description>
<link>https://storm.apache.org/</link>
<atom:link href="https://storm.apache.org/feed.xml"; rel="self"
type="application/rss+xml"/>
- <pubDate>Sat, 25 Jul 2026 17:04:52 +0000</pubDate>
- <lastBuildDate>Sat, 25 Jul 2026 17:04:52 +0000</lastBuildDate>
+ <pubDate>Sun, 23 Aug 2026 20:15:28 +0000</pubDate>
+ <lastBuildDate>Sun, 23 Aug 2026 20:15:28 +0000</lastBuildDate>
<generator>Jekyll v3.10.0</generator>
<item>
diff --git a/releases/3.0.0/Cluster-State-Serialization.html
b/releases/3.0.0/Cluster-State-Serialization.html
index c80f278746..e7d38e6d3f 100644
--- a/releases/3.0.0/Cluster-State-Serialization.html
+++ b/releases/3.0.0/Cluster-State-Serialization.html
@@ -192,6 +192,17 @@ ZooKeeper (and other configured state stores) such as
topology assignments, Nimb
summaries, <code>StormBase</code> records, log configs, credentials, worker
heartbeats,
profile requests, errors, etc.</p>
+<blockquote>
+<p><strong>Note on worker heartbeats.</strong> Since 2.0 (<a
href="https://issues.apache.org/jira/browse/STORM-2693";>STORM-2693</a>),
+worker liveness heartbeats are, by default, <em>not</em> persisted in
ZooKeeper: workers
+write them to local disk, supervisors relay them to Nimbus over Thrift, and
Nimbus
+keeps them in an in-memory heartbeat cache. Worker heartbeats are only written
to a
+state store (the <code>WORKERBEATS_SUBTREE</code> path) when a heartbeat store
such as Pacemaker
+is configured. The serialization described below still applies to those stored
+heartbeats, and to supervisor liveness (<code>SupervisorInfo</code>), which is
always kept as an
+ephemeral ZooKeeper node.</p>
+</blockquote>
+
<p>It is distinct from
<a href="Serialization.html">tuple serialization</a>, which covers payloads
exchanged
between spouts and bolts at runtime via Kryo.</p>
diff --git a/releases/3.0.0/Daemon-Fault-Tolerance.html
b/releases/3.0.0/Daemon-Fault-Tolerance.html
index 9b297d955d..b53db9868a 100644
--- a/releases/3.0.0/Daemon-Fault-Tolerance.html
+++ b/releases/3.0.0/Daemon-Fault-Tolerance.html
@@ -191,7 +191,7 @@
<h2 id="what-happens-when-a-worker-dies">What happens when a worker dies?</h2>
-<p>When a worker dies, the supervisor will restart it. If it continuously
fails on startup and is unable to heartbeat to Nimbus, Nimbus will reschedule
the worker.</p>
+<p>When a worker dies, the supervisor will restart it. Worker liveness reaches
Nimbus indirectly: each worker writes heartbeats to local disk, and its
supervisor relays them to Nimbus over Thrift (this replaced the pre-2.0 model
in which workers heartbeat directly into ZooKeeper; see <a
href="https://issues.apache.org/jira/browse/STORM-2693";>STORM-2693</a>). If a
worker stops heartbeating for longer than
<code>nimbus.task.timeout.secs</code>, Nimbus reschedules it. A freshly
launched wor [...]
<h2 id="what-happens-when-a-node-dies">What happens when a node dies?</h2>
@@ -203,6 +203,8 @@
<p>Most notably, no worker processes are affected by the death of Nimbus or
the Supervisors. This is in contrast to Hadoop, where if the JobTracker dies,
all the running jobs are lost. </p>
+<p>Supervisor liveness is tracked differently from worker liveness. Each
supervisor registers itself as an ephemeral ZooKeeper node (its
<code>SupervisorInfo</code>, which also carries scheduling metadata such as
ports and resources). When a supervisor dies, its ZooKeeper session expires and
the ephemeral node disappears, so Nimbus detects the loss directly from
ZooKeeper rather than by timing out heartbeats. (This is why there is no active
Nimbus-side supervisor heartbeat-timeout setting.)</p>
+
<h2 id="is-nimbus-a-single-point-of-failure">Is Nimbus a single point of
failure?</h2>
<p>If you lose the Nimbus node, the workers will still continue to function.
Additionally, supervisors will continue to restart workers if they die.
However, without Nimbus, workers won't be reassigned to other machines when
necessary (like if you lose a worker machine). </p>
diff --git a/releases/3.0.0/Lifecycle-of-a-topology.html
b/releases/3.0.0/Lifecycle-of-a-topology.html
index dd4a6ff8c7..de4f519fe8 100644
--- a/releases/3.0.0/Lifecycle-of-a-topology.html
+++ b/releases/3.0.0/Lifecycle-of-a-topology.html
@@ -227,7 +227,11 @@
<ul>
<li>Jars and configs are kept on local filesystem because they're too big
for Zookeeper. The jar and configs are copied into the path {nimbus local
dir}/stormdist/{topology id}</li>
<li><code>setup-storm-static</code> writes task -> component mapping into
ZK</li>
-<li><code>setup-heartbeats</code> creates a ZK "directory" in which
tasks can heartbeat</li>
+<li><code>setup-heartbeats</code> creates a ZK "directory" in which
tasks can heartbeat
+
+<ul>
+<li>(<strong>Since 2.0, STORM-2693</strong>: workers no longer heartbeat
directly into ZooKeeper. A worker now writes liveness heartbeats to local disk,
and its supervisor relays them to Nimbus over Thrift. See <a
href="Daemon-Fault-Tolerance.html">Daemon Fault Tolerance</a> for the current
mechanism.)</li>
+</ul></li>
</ul></li>
<li><p>Nimbus calls <code>mk-assignment</code> to assign tasks to machines <a
href="https://github.com/apache/storm/blob/0.7.1/src/clj/org/apache/storm/daemon/nimbus.clj#L458";>code</a></p>
diff --git a/releases/current/Cluster-State-Serialization.html
b/releases/current/Cluster-State-Serialization.html
index 92d228a32a..57c4d2923c 100644
--- a/releases/current/Cluster-State-Serialization.html
+++ b/releases/current/Cluster-State-Serialization.html
@@ -192,6 +192,17 @@ ZooKeeper (and other configured state stores) such as
topology assignments, Nimb
summaries, <code>StormBase</code> records, log configs, credentials, worker
heartbeats,
profile requests, errors, etc.</p>
+<blockquote>
+<p><strong>Note on worker heartbeats.</strong> Since 2.0 (<a
href="https://issues.apache.org/jira/browse/STORM-2693";>STORM-2693</a>),
+worker liveness heartbeats are, by default, <em>not</em> persisted in
ZooKeeper: workers
+write them to local disk, supervisors relay them to Nimbus over Thrift, and
Nimbus
+keeps them in an in-memory heartbeat cache. Worker heartbeats are only written
to a
+state store (the <code>WORKERBEATS_SUBTREE</code> path) when a heartbeat store
such as Pacemaker
+is configured. The serialization described below still applies to those stored
+heartbeats, and to supervisor liveness (<code>SupervisorInfo</code>), which is
always kept as an
+ephemeral ZooKeeper node.</p>
+</blockquote>
+
<p>It is distinct from
<a href="Serialization.html">tuple serialization</a>, which covers payloads
exchanged
between spouts and bolts at runtime via Kryo.</p>
diff --git a/releases/current/Daemon-Fault-Tolerance.html
b/releases/current/Daemon-Fault-Tolerance.html
index 02a29544b4..b329351146 100644
--- a/releases/current/Daemon-Fault-Tolerance.html
+++ b/releases/current/Daemon-Fault-Tolerance.html
@@ -191,7 +191,7 @@
<h2 id="what-happens-when-a-worker-dies">What happens when a worker dies?</h2>
-<p>When a worker dies, the supervisor will restart it. If it continuously
fails on startup and is unable to heartbeat to Nimbus, Nimbus will reschedule
the worker.</p>
+<p>When a worker dies, the supervisor will restart it. Worker liveness reaches
Nimbus indirectly: each worker writes heartbeats to local disk, and its
supervisor relays them to Nimbus over Thrift (this replaced the pre-2.0 model
in which workers heartbeat directly into ZooKeeper; see <a
href="https://issues.apache.org/jira/browse/STORM-2693";>STORM-2693</a>). If a
worker stops heartbeating for longer than
<code>nimbus.task.timeout.secs</code>, Nimbus reschedules it. A freshly
launched wor [...]
<h2 id="what-happens-when-a-node-dies">What happens when a node dies?</h2>
@@ -203,6 +203,8 @@
<p>Most notably, no worker processes are affected by the death of Nimbus or
the Supervisors. This is in contrast to Hadoop, where if the JobTracker dies,
all the running jobs are lost. </p>
+<p>Supervisor liveness is tracked differently from worker liveness. Each
supervisor registers itself as an ephemeral ZooKeeper node (its
<code>SupervisorInfo</code>, which also carries scheduling metadata such as
ports and resources). When a supervisor dies, its ZooKeeper session expires and
the ephemeral node disappears, so Nimbus detects the loss directly from
ZooKeeper rather than by timing out heartbeats. (This is why there is no active
Nimbus-side supervisor heartbeat-timeout setting.)</p>
+
<h2 id="is-nimbus-a-single-point-of-failure">Is Nimbus a single point of
failure?</h2>
<p>If you lose the Nimbus node, the workers will still continue to function.
Additionally, supervisors will continue to restart workers if they die.
However, without Nimbus, workers won't be reassigned to other machines when
necessary (like if you lose a worker machine). </p>
diff --git a/releases/current/Lifecycle-of-a-topology.html
b/releases/current/Lifecycle-of-a-topology.html
index cb3fbf4c99..4601d4e5b3 100644
--- a/releases/current/Lifecycle-of-a-topology.html
+++ b/releases/current/Lifecycle-of-a-topology.html
@@ -227,7 +227,11 @@
<ul>
<li>Jars and configs are kept on local filesystem because they're too big
for Zookeeper. The jar and configs are copied into the path {nimbus local
dir}/stormdist/{topology id}</li>
<li><code>setup-storm-static</code> writes task -> component mapping into
ZK</li>
-<li><code>setup-heartbeats</code> creates a ZK "directory" in which
tasks can heartbeat</li>
+<li><code>setup-heartbeats</code> creates a ZK "directory" in which
tasks can heartbeat
+
+<ul>
+<li>(<strong>Since 2.0, STORM-2693</strong>: workers no longer heartbeat
directly into ZooKeeper. A worker now writes liveness heartbeats to local disk,
and its supervisor relays them to Nimbus over Thrift. See <a
href="Daemon-Fault-Tolerance.html">Daemon Fault Tolerance</a> for the current
mechanism.)</li>
+</ul></li>
</ul></li>
<li><p>Nimbus calls <code>mk-assignment</code> to assign tasks to machines <a
href="https://github.com/apache/storm/blob/0.7.1/src/clj/org/apache/storm/daemon/nimbus.clj#L458";>code</a></p>
