Broken version history

Inconsistent version history can cause problems in Magnolia whenever you need to work with a past version of a node.

If a version history is broken, you see the exception org.apache.jackrabbit.core.state.NoSuchItemStateException in the log files.

2015-10-16 15:30:17,766 ERROR - [] - ajp-nio-10202-exec-6 - info.magnolia.ui.contentapp.browser.action.RestoreVersionAction -
Restoring of version failed. failed to build path of d580f568-677b-41dc-aaa2-eee90f06c23a
javax.jcr.ItemNotFoundException: failed to build path of d580f568-677b-41dc-aaa2-eee90f06c23a
...
...
Caused by: org.apache.jackrabbit.core.state.NoSuchItemStateException: d580f568-677b-41dc-aaa2-eee90f06c23a

To fix these types of issues you can use the system parameter: org.apache.jackrabbit.version.recovery

To use the parameter, do the following:

  1. Stop Magnolia.

  2. Add the JVM parameter: -Dorg.apache.jackrabbit.version.recovery=true

    setenv.sh
    # Check for the existence of $JDKPath (which might be a variable that was substituted by an external script, i.e installer)
    if [ -d "$JDKPath" ] ; then
      export JAVA_HOME="$JDKPath"
    fi
    
    # to enable version recovery:
    export CATALINA_OPTS="$CATALINA_OPTS -Dorg.apache.jackrabbit.version.recovery=true -XX:MaxPermSize=256m -Xms64M -Xmx1024M -Djava.awt.headless=true"
    # default options:
    # export CATALINA_OPTS="$CATALINA_OPTS -XX:MaxPermSize=256m -Xms64M -Xmx1024M -Djava.awt.headless=true"
    # to enable jmx:
    # export CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"
    # to enable debugging:
    # export JPDA_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=54455,suspend=n,server=y"
    
    CURDIR=`dirname "$0"`
    if [ -e "${CURDIR}/magnolia_banner.txt" ] ; then
      cat ${CURDIR}/magnolia_banner.txt
    fi
  3. Start Magnolia.

When enabled, this feature looks for all versionable nodes in the repository, and checks whether the respective version history exists. If it is not the case, the recovery procedure removes broken reference to the version store.

Disable the JVM parameter once you have recovered from a corrupted version history. After recovery, there is no benefit to keeping the property enabled and leaving it enabled can have serious side effects, for example:

  • Deploying a new webapp to a JVM that has the property enabled can prevent the repository initializing correctly.

  • When enabled, the property delays startup times significantly.

Feedback

DX Core

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the DX Core docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules