How To Reset Revisions On The Scheduler And Runtimes And Identify When This Should Be Done (Doc ID 2009225.1)

Last updated on AUGUST 25, 2017

Applies to:

Oracle Knowledge - Version 8.2 and later
Information in this document applies to any platform.

Goal

This article provides instructions on how to reset revisions on the Scheduler/Indexer and Search Runtime instance. It also provides guidance on some common symptoms that suggest this course of action is required.

 

Terms used within this article:

Revision: A revision in effect defines the configuration of the Scheduler with respect to collections, Jobs, language configuration and configuration of the Search environment at the point in time when the configuration/revision was created. A revision is represented as an XML file in the directory "<INQUIRA_INSTALL>\instances\<WebApp name>\<[development|staging|production]>\content\data\revision\default\revision\". For example: "<INQUIRA_INSTALL>\instances\MySearch\development\content\data\revision\default\revision\00025882.xml" These configuration files are typically referred to as "number XML files" or "#.xml" files.

A revision is not an "Index". An "Index" is the result of performing content processing steps utilizing the current highest number XML file.

Bundle: A bundle consists of one or more data files created when content processing is performed. It contains details of the current configuration at the point in time when the processing was performed together with the resulting index/dictionary/navigation data structures that may have been created. A bundle is associated with a revision. Bundles can be found in the directory "<INQUIRA_INSTALL>\instances\<WebApp name>\<[development|staging|production]>\content\data\revision\default\bundles\". For example: "<INQUIRA_INSTALL>\instances\MyCompany\development\content\data\revision\default\bundles\00000543" It is the bundles that are transferred to the runtime instances during the Synchronization task.

 

 

Common indicators that a Reset Revisions is an appropriate course of action:

a) The Indexer or Workclients start failing with Log_Store_Exceptions or UserData exceptions, your crawl has failed with an OutOfMemory exception or some unexpected circumstance and your crawl cannot recover.

b) The Indexer jobs start failing at the Synchronization task with messages that hint at corrupted or missing revision *.xml files such as:

[59 DeployerThread (1)] UNKNOWN MESSAGE ID "REVISION_PARSE_FAILED" called with: "<INQUIRA_INSTALL>\instances\<app>\<env>\content\data\revision\default\revision\00025882.xml" "com.inquira.util.xml.NodeBuilderException: Premature end of file.(-1:-1)"
com.inquira.util.xml.NodeBuilderException: Premature end of file.(-1:-1)
at com.inquira.util.xml.AbstractNodeBuilder.process(AbstractNodeBuilder.java:247)
at com.inquira.util.xml.AbstractNodeBuilder.process(AbstractNodeBuilder.java:223)
...

c) When the accumulation of past revisions and bundles has resulted in a considerable grown in the consumption of disc space over time. (It is recommended that the disc space consumed by the Indexer and Runtime instances is monitored as part of normal good housekeeping practices.)

d) When the Indexer (and/or Runtimes) revisions were partially corrupted due to unexpected filesystem failure (such as exhaustion of free disc space, network mounted folder unreachable, ...)

 

Solution

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms