Bug fix, , 2 min read
Plan B fixes in the 7.13 betas
Histograms and metrics no longer double count after an interrupted merge, queued data survives a restart, and sends retry through a network blip.
Plan B is Stroom's state store. It holds the state, sessions, metrics, histograms and traces that pipelines look up while they process events. When it gets something wrong, the error is quiet: a count that is slightly too high, or an enrichment that is missing. Several fixes in 7.13-beta.10 and 7.13-beta.11 close off the ways that could happen.
No more double counting (#5696)
Symptom. Histogram and metric stores could count the same data twice if a merge was rerun. That could happen after an interrupted shutdown, a duplicate part delivery or a sender retry.
Fix. Each part shard now carries an instance UUID, and additive stores track merge progress for each source. Fully merged sources are skipped, and an interrupted merge resumes exactly after its last commit.
Queued data survives a restart (#5696)
Symptom. At startup the merge processor could delete data that was queued but not yet merged. At shutdown, merge queue consumers could churn through the queue while their merges were being interrupted.
Fix. Data queued for merge now survives a restart, and interrupted merges are rerun the next time the merge job runs.
Lookups against a store that has not changed (#5705)
Symptom. Once the snapshot of an unchanged store aged out, lookups against it failed. The server's "not modified" (HTTP 304) response was being treated as a failure.
Fix. A 304 is now treated as "your copy is still current".
A related change (#5689) reworks how snapshots are served. Slightly stale snapshot data is now served, bounded by minTimeToKeepSnapshotEnv, while a refresh happens in the background. Startup cleanup also no longer deletes snapshots published by a node that stores shards.
Retrying through a network blip (#5706)
Symptom. A transport-level failure while sending Plan B data to a node, such as a DNS lookup failing during a brief outage, failed the send outright.
Fix. Sends now retry. Two new properties control this: stroom.planb.sendPartAttempts (default 3) and stroom.planb.sendPartRetryDelay (default 10s). The failure is also logged at debug level now rather than error, because it is rethrown and reported by the caller anyway.
Who should upgrade
Anyone on the 7.13 betas using Plan B metric or histogram stores. The double-counting fix is the one to prioritise.
How it works, in detail: Docs: Plan B / LMDB Data Store
Want this running on your own data? The engineers who built it can help.