Skip to content

Scheduled Jobs

Every background job Stroom runs, which nodes should run it, and what stops when it is off.

Stroom does most of its work in scheduled background jobs: processing, retention, indexing, statistics and housekeeping are all jobs rather than things that happen by themselves. They are listed under Monitoring → Jobs, where each can be enabled, disabled and rescheduled.

There are 48 jobs you can control, and 7 more that always run.

Warning

A disabled job does not report anything. The work simply never happens, and the symptom turns up somewhere else entirely and much later: data that never merges, streams that are never retained, indexes that never flush, disks that never empty. Before investigating anything that looks like slowness or missing data, check this screen first.

Note

On a new installation, pipeline processing is off. Processor Task Creator ships disabled, and it is the job that turns processor filters into work; Data Processor, which does that work on each node, ships disabled too. Until both are enabled nothing is processed, however many worker nodes are running and however correct the pipelines are, and nothing says so. It is the first thing to check on a system that receives data happily but never processes any.

The job list in Stroom, each job with a checkbox showing whether it is enabled and a description of what it does. Enabled jobs include Data Delete, Data Processor, Git Repo Push, Node Status, Processor Task Creator, Query History Clean and Account Maintenance.
The Jobs screen. The checkbox is the job's own switch; opening a row shows one like it per node, which is where the decision actually gets made.

How jobs and nodes fit together

Each node keeps its own switch for every job. The Jobs screen shows a row per job, which opens to a row per node, so "enabled" is really a decision per node rather than one for the cluster. A new node writes its own set of these rows when it first starts, taking each job's default, which is why a node added later comes up running everything the others do.

The Nodes column in the tables below says what to aim for.

Every node acts on this node's own caches, files and tasks Node A runs Node B runs Node C runs One at a time enabled everywhere; the cluster lock elects one Node A holds the lock Node B skips this turn Node C skips this turn One node shared state, no lock, so one is enough Node A enabled Node B off Node C off
The three patterns. Only the third is a decision about which nodes to enable; the first two are enabled everywhere and differ in whether a lock decides who actually does the work.
  • Every node. The job acts on the node it runs on: its caches, its open files, its share of the index, its own tasks. Turning it off on one node silently stops that part of the work on that node alone, which is the hardest kind of fault to spot: the cluster looks healthy and one node quietly misbehaves. Leave these on everywhere.
  • One at a time. The job takes a cluster lock, so although it is enabled everywhere only one node runs it at a time and the rest skip that turn. Leave these on everywhere too: the lock stops duplicate work, and having every node willing to run it means the work still happens when any one node is down. Narrowing one of these to a single node removes that cover without saving anything.
  • One node. The work is on shared state and takes no lock, so one node is enough. Leaving these on everywhere is safe rather than harmful (the work is repeated and mostly finds nothing to do), but on a large cluster it is needless database traffic, and confining them to a node or two is a reasonable tidy-up.

Turning a job off

Most of these jobs are housekeeping, and the cost of switching one off is paid later rather than immediately: a table that grows, a disk that fills, an index that drifts out of date. The What it does column says what stops in each case.

Worth turning on deliberately: the analytics and reporting jobs, which do nothing until you use those features, and the two orphan finders, which are diagnostics to run when you suspect the data store and the database disagree.

Worth leaving off: Data Generator, which makes synthetic data, and Java Heap Histogram Statistics, which pauses the JVM while it runs.

Note

After changing a job, confirm it on the same screen: the node row shows its last run and its next scheduled run. A job that is enabled but whose last-run time does not move is a job that is failing rather than working, and the cause will be in that node's logs.

Receiving data

JobWhat it doesNodesOn by default
Data GeneratorGenerates synthetic data into a feed. A testing aid: leave it off on a real system.One nodeNo
S3 Event Notifications PollPolls an AWS SQS queue for S3 event notifications. On only if you ingest from S3.One nodeNo

Processing

JobWhat it doesNodesOn by default
Data ProcessorRuns the processing tasks this node claims. Off on a node, that node processes nothing; off on every node, tasks are created and queue up but no stream is ever processed, and nothing reports an error.Every nodeNo
Pipeline Destination RollCloses and rolls this node's open output files on their schedule. Off, rolling destinations on this node stay open and downstream systems see nothing arrive.Every nodeYes
Processor Task CreatorThe source of all pipeline processing. With it off, no new tasks are created and processing stops cluster-wide, however many workers are running.One at a timeNo
Processor Task HeartbeatMarks the tasks this node is working on as alive. Off, this node's running tasks look abandoned and another node will take them back and repeat the work.Every nodeYes
Processor Task Manager Release Old Queued TasksFrees tasks queued by a master node that has gone. Only does anything when claimTasksOnWorker is off.One nodeYes
Processor Task Queue StatisticsRecords queue depth for monitoring. Safe to leave off if you do not chart it. Only does anything when claimTasksOnWorker is off.One nodeYes
Processor Task ReaperRecovers tasks from a node that died. Off, work in flight on a lost node is never picked up again and those streams are silently never processed.One at a timeYes
Processor Task RetentionDeletes finished task records. Off, the task table grows without limit and the processing screens get slower.One at a timeYes

Data lifecycle

JobWhat it doesNodesOn by default
Annotation RetentionRemoves annotations past their retention. Off, old annotations stay.One at a timeYes
Attribute Value Data RetentionTrims stored stream attribute values. Off, that table grows and attribute searches slow down.One at a timeYes
Data DeleteDoes the real deletion of data already marked as deleted. Off, nothing is reclaimed and the volumes keep filling.One at a timeYes
Policy Based Data RetentionApplies your retention policy. Off, data is kept past its policy, which is usually a compliance question rather than a disk one.One at a timeYes

Storage

JobWhat it doesNodesOn by default
File System Volume StatusRefreshes how full each data volume is. Off, Stroom writes against stale free-space figures and can fill a volume it believes has room.One at a timeYes
Orphan File FinderReports files on disk with no metadata. A diagnostic: turn it on when you suspect the store and the database disagree, rather than leaving it running.One at a timeNo
Orphan Meta FinderReports metadata with no files behind it. The same diagnostic from the other side.One at a timeNo

Indexing

JobWhat it doesNodesOn by default
Index Shard DeleteRemoves shard files already marked deleted from this node's disks. Off, the space is never returned.Every nodeYes
Index Shard RetentionMarks shards past their retention as deleted. Off, old shards are kept and searched.One nodeYes
Index Volume StatusRefreshes free space for the index volumes this node owns. Off, this node can fill an index volume it believes has room.Every nodeYes
Index Writer Cache SweepCloses index writers this node has finished with. Off, the node holds file handles and memory it no longer needs.Every nodeYes
Index Writer FlushCommits this node's index writers to disk. Searches see new documents without it, but off, the Shards tab's Doc Count never updates and uncommitted documents are lost if the node stops without shutting down cleanly.Every nodeYes
Solr Index OptimiseCompacts Solr indexes. Only relevant if you use Solr indexing.One at a timeYes
Solr Index RetentionApplies deletion queries to Solr indexes. Only relevant if you use Solr indexing.One at a timeYes

State stores

JobWhat it doesNodesOn by default
Plan B Maintenance ProcessorApplies condense and retention rules to this node's shards. Off, shards keep growing.Every nodeYes
Plan B Merge ProcessorMerges this node's incoming state batches into its shards. Off, state stores stop advancing and lookups return increasingly stale answers.Every nodeYes
Plan B Shared FS HousekeepingClears orphaned directories and unused local copies from the shared store. Only relevant with a shared file store.Every nodeYes
Plan B Shared FS MergeThe shared-filesystem form of the merge. Only relevant with a shared file store.One at a timeYes
Plan B Snapshot CleanupDeletes snapshots nothing is reading. Off, snapshot storage grows.Every nodeYes
Plan B Snapshot CreatorPublishes snapshots other nodes read. Off, readers fall back to older snapshots.Every nodeYes

Reference data

JobWhat it doesNodesOn by default
Ref Data Off-heap Store PurgePurges old reference loads from this node's own off-heap store. The store is per node, so a node where this is off keeps growing on disk whatever the others do.Every nodeYes

Statistics

JobWhat it doesNodesOn by default
SQL Stats Database AggregationRolls fine-grained statistics up into coarser buckets. Off, the statistics tables grow quickly and statistic queries slow down.One at a timeYes
SQL Stats In Memory FlushWrites this node's buffered statistics to the database. Off, this node's statistics are never recorded and are lost on restart.Every nodeYes

Analytics

JobWhat it doesNodesOn by default
Analytic Execution History RetentionTrims the record of past analytic runs. On if you run analytics and want the history bounded.One nodeNo
Analytic Executor: Scheduled QueryRuns scheduled analytic queries. On only if you use analytics.One nodeNo
Analytic Executor: Table BuilderBuilds the tables scheduled analytics query. On only if you use analytics.One nodeNo
Process PathwaysTurns trace data into pathways. On only if you use pathways.One at a timeYes
ReportsRuns scheduled reports. On only if you have reports to run.One nodeNo

Content

JobWhat it doesNodesOn by default
Doc Store - Physical DeleteReally deletes documents left in the recycle state past their retention. Off, they stay and remain recoverable.One nodeYes
Git Repo PushPushes content changes to a remote Git repository. On only if you have set one up.One at a timeYes
Query History CleanTrims saved query history. Off, the history table grows.One nodeYes
Reindex ContentRebuilds the index behind "Find in content". Needed only on nodes serving the user interface, and on shared storage one node of any kind is enough.One at a timeNo

Identity

JobWhat it doesNodesOn by default
Account MaintenanceDisables accounts that have gone unused. Only applies to the internal identity provider, and off means dormant accounts stay enabled.One nodeYes
Identity Key RotationRotates the token signing keys. Off, keys are never retired. Internal identity provider only.One nodeYes
Identity Token PurgeClears expired token rows. Housekeeping only: expired tokens are already refused on every read, so this reclaims space rather than enforcing anything.One nodeYes

Node and cluster

JobWhat it doesNodesOn by default
Java Heap Histogram StatisticsA deep JVM diagnostic that pauses the JVM while it runs. Leave it off unless you are chasing a memory problem and accept the pause.Every nodeNo
Node StatusRecords this node's CPU and memory as internal statistics. Off, that node's figures stop while it carries on working.Every nodeYes
Property Cache ReloadPicks up property changes made on another node. Off, this node keeps running on the values it started with and quietly behaves differently from the rest.Every nodeYes

Jobs you do not control

These run on every node and are not listed in the Jobs screen, because there is no useful reason to turn them off: Clear Old Schemas, Delete temp resource files, Evict expired elements, Evict from object pool, Fetch new tasks, Flush Data Attributes To DB, Stepping Store Cleanup.

All documentation