WARN org.apache.jackrabbit.core.query.lucene.DocId$UUIDDocId - Unknown parent node with id ...ERROR ... failed to read bundle: ...
These problems can have multiple causes. Possible causes (depending on the CRX version) are:
The most common cause is concurrent modification using the same session. In this case, the CRX error.log file most likely contains at least one ConcurrentModificationException.
These symptoms indicate that the index (and possibly also the workspace) might be inconsistent.
Usually, the impact of an inconsistency is low. One problem is that the log file is filled with error messages due to an inconsistency.
Search index inconsistencies can happen because of the following:
There are two ways to fix search index inconsistencies:
You can run an index consistency check on startup. In the workspace.xml add two parameters in the <SearchIndex class="..."> element:
<param name="enableConsistencyCheck" value="true"/> <param name="forceConsistencyCheck" value="true"/>
A third parameter controls whether errors should be repaired or if they should be logged only:
<param name="autoRepair" value="false"/> <!-- default is true -->
<SearchIndex class="com.day.crx.query.lucene.LuceneHandler"> <param name="path" value="${wsp.home}/index"/> <param name="enableConsistencyCheck" value="true"/> <param name="forceConsistencyCheck" value="true"/> <param name="autoRepair" value="true"/> </SearchIndex>
Re-creating your search index will fix all search index inconsistencies. However, it takes considerably longer than the search index consistency check and fix. Due to this, take special care when planning a search index rebuild and if you cannot afford much downtime consider doing a check and fix instead.
Planning your Index Rebuild
Since the time required to rebuild your index depends on many different factors (such as the total number of nodes, asset file sizes, and asset file types) you should test rebuilding out in a non-production environment first. Use the non-production test to calculate how long of an outage window you will need in production. Small repositories in the 2-10GB size can take anywhere from 30 minutes to 6 hours and larger ones can take anywhere from 6 hours to 2 days.
How to Rebuild the Index
To rebuild your search index, do the following:
If that doesn't help and it prints errors that cannot be repaired, then it is likely that the workspace data is inconsistent.
Persistence managers can check repository consistency and fix problems at startup. To enable consistency checking and automatically fix problems, add the following parameters in the repository.xml and workspace.xml within each <PersistenceManager class="..."> element, and re-start CRX.
In a default CQ5.2.X installation these files can be found under crx-quickstart/repository/workspaces/*/workspace.xml and crx-quickstart/server/runtime/0/_crx/WEB-INF/repository.xml.
In CQ5.3, repository.xml can be found under crx-quickstart/repository/repository.xml instead.
<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"> <param name="consistencyCheck" value="true" /> <param name="consistencyFix" value="true" /> </PersistenceManager>
Either check/fix (index or persistence manager) will be performed on the next startup. After the consistency check has finished, disable the relevant settings, otherwise the consistency check always runs when starting up CRX.
If only consistencyCheck is enabled, then a file inconsistentBundleIds.txt is created in the workspace directory.
If only consistencyFix is enabled, then the file inconsistentBundleIds.txt is read, and those nodes are fixed. The file is then deleted if everything could be fixed.
When running a consistency fix in a clustered environment, only run it on one cluster node. Don't start other cluster nodeswhile the consistency fix is running. After it is finished, the othercluster nodes can be started.
The consistency check scans all nodes and therefore is slow. To reduce the maintenance time, consider running the consistency check on a copy of the repository, and then just fix the nodes that are corrupt. Use the following steps to do this:
To limit the consistency check and fix to a list of nodes, add the UUIDs of those nodes in the configuration option "consistencyCheckUUIDs":
<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"> <param name="consistencyCheck" value="true" /> <param name="consistencyCheckUUIDs" value="ea9cb12f-8a8f-4820-88b1-6d1c496a07cd,741c905c-cfb0-422f-acd4-e0a9cbde46c6" /> <param name="consistencyFix" value="true" /> </PersistenceManager>
As of CRX 2.2, you can add this jvm parameter to the CRX/CQ5 startup to prevent corruptions:
-Dorg.apache.jackrabbit.core.state.validatehierarchy=true
If you are using the quickstart CQSE server then you can add the parameter to the JVM_OPTS variable, for example:
crx-quickstart\server\server.bat (Windows):
set JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true
or crx-quickstart/server/start (Mac & Linux):
export JVM_OPTS=-XX:MaxPermSize=256m -Dorg.apache.jackrabbit.core.state.validatehierarchy=true
Use of the validateheirarchy system property causes a slight degradation in performance of session save operations in the repository. When planning to use this feature, it is suggested that you do load testing beforehand to see what impact it has. It especially applies if you have a write-heavy application.
Make sure to disable tar optimization when the consistency check is planned to run to avoid running tar optimization & consistence check in parallel.
1.X, 2.X
Sign in to your account