Transparent Restore or Startup
Note
|
This feature is available in Azul Zulu 25 and the October 2025 releases. |
By default, when a restore attempt fails, the JVM immediately exits with an error. The -XX:+CRaCIgnoreRestoreIfUnavailable
command-line option allows altering this behavior, making the JVM proceed with the usual initialization if it is not possible to restore from the specified CRaC checkpoint image. For example, when the image does not exist or the current machine has insufficient CPU features.
This option is aimed to simplify the use of CRaC. It is mainly targeted at stateless apps for which restoring from a checkpoint or starting a new run from the classes results in the same behavior.
Image Validation is Limited
The verification performed on the specified checkpoint image does not cover all possible errors that may happen during a restore. This means that it is possible for the restore to fail even when the verification checks pass.
The aim of the verification is to determine if the specified CRaC image is compatible with the current environment. It’s assumed that the image is correct (e.g., has not been corrupted) and the environment is properly configured (e.g., has enough memory for the CRaC engine to function).
Usage Instructions
To use this option, you create a checkpoint in a canary environment as usual, and in the production environment you use a command like this:
java -XX:CRaCRestoreFrom=crac-image \
-XX:+CRaCIgnoreRestoreIfUnavailable \
-jar my_app.jar arg1 arg2
In this example, the JVM will first try to locate the directory crac-image
and check if it is compatible with the current environment, resulting in:
-
If the checkpoint image validation succeeds: Restore from the image will be initiated. The
-jar my_app.jar arg1 arg2
part of the command line will be ignored. -
If the checkpoint image validation fails: The JVM determines that restore from
crac-image
is not possible and will instead use-jar my_app.jar arg1 arg2
to start the application.