Quick answer
When Documentum search stops returning documents that you know exist, the cause is almost always in the indexing pipeline, not the search interface. Start with the index agent: if it is stopped or stalled, documents keep saving normally while the xPlore index quietly goes stale. Queue backlog, content-extraction failures, and xPlore itself come next.
This is the defining trait of Documentum full-text failures: nothing errors on the way in. Users create and save documents, workflows advance, the Content Server is healthy — and search results are simply missing the last three days. Attribute-based DQL still finds everything, which is the tell that the repository is fine and the index is behind.
01 — What You’re Seeing
New documents save fine, but search can’t find them
The symptoms that point at the indexing pipeline rather than the client.
The pattern: recently saved documents don’t appear in D2, Webtop, or DFC/REST search results; a SEARCH DOCUMENT CONTAINS DQL returns nothing while the equivalent attribute query returns rows; results stop at a date in the past; or search works in one repository but not another on the same xPlore instance.
One warning before you trust your admin console: Documentum Administrator can display the wrong index agent status. DA has a documented habit of reporting an index agent state that doesn’t match reality, so a green status in DA proves nothing either way. Always confirm in the index agent’s own console. The full set of what Reveille checks across this pipeline — agent, queue, CPS, and xPlore — is published in the Reveille for Documentum technical overview.
02 — Causes, Ranked
Five causes, in the order you should check them
Documents flow from the Content Server queue, through the index agent and CPS, into xPlore. Search fails when any link stalls.
1. The index agent is stopped or stalled (most common)
The agent’s JVM can be running while the agent itself sits in a stopped or shutdown state — surviving a server reboot in exactly this condition is a classic. Open the agent’s own console, by default http://<host>:9200/IndexAgent, and confirm the status is Running.
2. The queue is backed up
The agent is running but hours or days behind — typical after a bulk load, migration, or lifecycle job that queued hundreds of thousands of items. Measure it directly:
A count that climbs while the agent reports Running means processing has effectively stalled; a large but falling count just means it’s catching up.
3. CPS is failing to extract content
The Content Processing Service does the text extraction, and individual documents fail it — corrupt files, password-protected PDFs, oversized content, or a CPS daemon that has exhausted memory. Failed items show as task_state = 'failed' in dmi_queue_item, and the CPS daemon log tells you why.
4. xPlore itself is unhealthy
The dsearch instance is down, the xPlore data directory has filled its disk, or a collection is in a bad state. Check the dsearch admin console (by default http://<host>:9300/dsearchadmin) and disk space before anything else.
5. Configuration drift after an upgrade or clone
The fulltext plugin inactive for the docbase, xQuery search disabled for the repository, or an index agent still pointed at its source repository after an environment clone. This is the least frequent cause — and the one that eats the most hours, because everything reports healthy.
| Cause | How to confirm | Fix |
|---|---|---|
| Index agent stopped or stalled | Agent console (:9200/IndexAgent) shows Stopped — don’t trust DA | Restart the agent from its console; verify queue count starts falling |
| Queue backlog | DQL count on dmi_queue_item high and not falling | Let it drain if falling; if flat, restart the agent and check CPS throughput |
| CPS extraction failures | task_state = ‘failed’ rows; CPS daemon log errors | Fix or exclude the offending documents, restart CPS, resubmit failed items |
| xPlore instance / disk | dsearch admin unreachable; data directory disk full | Free space or extend the volume, restart dsearch, verify collections online |
| Config drift after upgrade/clone | Fulltext plugin or xQuery search disabled for the repository | Re-enable, re-run agent config against the correct repository, then ftintegrity |
03 — The Fixes
How do you get the index caught up and complete?
Restart what’s stalled, resubmit what failed, then verify nothing is missing.
- Restart the index agent from its own console and watch the queue count for ten minutes. Falling means fixed; flat means the problem is downstream in CPS or xPlore.
- Resubmit failures. Pull the failed set with
SELECT item_id, message FROM dmi_queue_item WHERE task_state = 'failed', fix what’s fixable (replace corrupt files, exclude password-protected formats), and resubmit from the index agent console. If CPS logs show memory pressure, restart the CPS daemon and consider raising its allocation before resubmitting a large batch. - Verify completeness with ftintegrity. After any stall, run the ftintegrity tool to compare what the repository holds against what the xPlore index contains, and reindex the mismatch list it produces. This is the step most teams skip — and the reason “we fixed it last month” environments still have a hole in their search results from the outage window.
- For config drift, confirm the fulltext plugin is active and xQuery search is enabled for the repository, re-run the agent configuration against the correct docbase, then ftintegrity again to fill the gap.
That resolves the incident. The harder problem is that this failure mode produces no incident until a user complains — which is a prevention problem, not a repair problem.
04 — Stop It Recurring
Why does a stale index go unnoticed for weeks?
Because platform health checks watch the server, and this failure lives in the pipeline.
Every cause above shares one property: the platform stays green while the workflow degrades. Infrastructure tools see a running JVM and a responsive database; they don’t know what a healthy indexing pipeline looks like. Catching this class of failure early means continuously watching the pipeline itself — agent status at the JMX level, pending and failed queue depths, CPS availability — and validating real queries end-to-end, so the alert fires when indexing stalls, not when a user escalates.
Reveille for Documentum
Reveille’s pre-configured test library — more than 100 Documentum Content Management–specific tests — includes an xPlore indexing suite that tracks Index Agent Status, Index Pending Count, Index Failed Count, Index Warning Count, CPS instance availability, and xQuery search enablement per repository, alongside DFS, REST, and CMIS query tests that validate real search results within a threshold service level. See how agentless Documentum observability works →
We covered the other silent failure modes in the 4 most common Documentum issues we see in production. Search staleness belongs on that list: measured continuously, it’s a five-minute alert; discovered by users, it’s a lost week and an OpenText Documentum Content Management support case you could have avoided.
Frequently asked questions
