HomeEE · Operations › Index management

Index management

Purpose: Operate Oak indexes: deployment, reindexing, monitoring lag and keeping definitions healthy as content grows.

Who this page is for

AudienceWhy it matters to you
Platform engineersOperators
Backend engineersIndex definition owners

Index types you operate

TypeBacksOperational trait
Lucene (async)Full-text + most property queriesIndexed asynchronously — lag exists by design
Property (synchronous)Unique/critical lookupsImmediate but write-cost on every commit
Counter/nodetype internalsSystemLeave alone

Async lag consequence: content saved a moment ago may not be query-visible for seconds. Code that writes-then-queries must not assume immediacy (queries).

Deploying index changes

Monitoring

SignalMeaning
Async indexing lag (JMX IndexStats: lastIndexedTime drift)Indexing falling behind writes — investigate before queries "lose" content
Traversal warnings in error.logA query lost its index — new code or definition regression (slow queries)
Index disk growthDefinitions indexing too much (includedPaths/properties too broad)
Reindex jobs running unexpectedlySomeone set reindex=true in prod — find out who and why

Definition hygiene

Scope tightly: includedPaths to your content roots, only queried properties, analyzed only where full-text is real. Every custom index has an owner comment (which feature/query needs it) — orphan indexes accumulate write cost forever and nobody dares delete undocumented ones.

Quick navigation