[crac] RFR: Provide arguments for restore [v5]

Ashutosh Mehra duke at openjdk.java.net
Fri Apr 1 16:20:07 UTC 2022


On Thu, 24 Mar 2022 14:52:48 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> I can imagine that a micro-service may need to know coordinates of other services on restore. Command line arguments may be used to provide the path to a config file then.

@AntonKozlov Thanks for the explanation. This makes the requirement a lot more clear now.

I have a slightly different take on the application's perspective for this requirement. I am looking at the need for new arguments as no different than the post-restore adjustments that the application may have to do. Currently this is implemented using `Resource` interface and I feel the same mechanism can be extended for handling the new arguments at the application level as well. This can be done by treating the class responsible for processing arguments as a `Resource` which would get the `afterRestore` notification and can then get the new arguments from the Context passed to it.

For instance, in the JavaCompilerCRaC example, `JavaCompilerCRaC` can extend `Resource`, implement `afterRestore()`, get the new args from the `Context` and make internal adjustments which could be reading the config file, or opening a socket on the port number, or in this example call `runJavac()`.

I have created a [patch](https://github.com/ashu-mehra/crac/commit/3360123f4d4671bfdcee129115300d0f108d3d8f) on top of your changes to highlight this behavior.

This approach also removes the requirement for the application to create another main class to be used only on restore. In fact, the user can just do `java -XX:CRaCRestoreFrom=<dir> arg1 arg2` and the new arguments  would be available to the application on restore. 

Your thoughts on this approach?

-------------

PR: https://git.openjdk.java.net/crac/pull/16


More information about the crac-dev mailing list