Inconsistent version history can cause malfunction of many CQ operations, including replication, version restoration, and content package installation.
If a version history is broken, you see the exception org.apache.jackrabbit.core.state.NoSuchItemStateException in the log files. And, you see the same thing in the stack trace classes from the package org.apache.jackrabbit.core.version.
Use system parameter "org.apache.jackrabbit.version.recovery:"
To apply the parameter, do the following:
- Install the latest CRX2.2 hot fix. You can request the latest CRX hot fix by submitting a support ticket. Follow the hot fix installation instructions and make sure to restart CQ after installing it.
- Stop CQ/CRX.
- Add the jvm parameter to the startup script: -Dorg.apache.jackrabbit.version.recovery=true
- Start CQ/CRX.
- Check the java process status (for example, ps -ef | grep java) to verify that the new parameter is used.
If it is not the case, the recovery procedure removes broken reference to the version store. In particular mix:versionable mixin, and properties jcr:versionHistory, jcr:baseVersion, jcr:predecessors and jcr:isCheckedOut. It enables the repository to create new version graph for the node, the time it's required.
- Stop the instance.
- Delete the version folder and repository/repository/index folder.
- (Optional) Add consistency/check fix in the crx.default workspace.xml for the Tar Persistence Manager data.
- Add -Dorg.apache.jackrabbit.version.recovery=true
- Start the instance (it can take several hours or days depending your data size and I/O performances, so consider testing on a copy first.
- When the instance is ready, create a package from /etc/workflow/models.
- Delete the /etc/worflow/models (using CRXDE or CRX Explorer).
- Install the package you just created over to re-create the workflow models.
Note: Starting in CRX 2.2, the parameter described in the following article helps avoid inconsistencies.