CRaC: ignore checkpointOnRefresh afterRestore

[frederikz]

You do a spring.context.checkpoint=onRefresh. You do a CRaC restore. Your restored application needs to adapt its configuration which leads to a context refresh event which results in another checkpoint beeing created and the JVM exits.

Shouldn't checkpointOnRefresh be set to false in DefaultLifecycleProcessor in afterRestore (or after it was executed) or some other mechanism implemented that prevents the checkpointOnRefresh mechanism to be executed on a restored JVM? To me spring.context.checkpoint is an easy way to create a checkpoint and should never be executed on a restored JVM.

[sdeleuze]

After the restoration, the execution is expected to resume after the point where checkpointOnRefresh is evaluated so I believe the current behavior is correct, and we have multiple tests checking that the behavior is correct on https://github.com/spring-projects/spring-lifecycle-smoke-tests.

Do you observe a concrete issue (if so, please provide a reproducer)?

[frederikz]

Yes, the after restore behavior is correct. But is a context refresh event an event that only occurs once in the lifetime of an application or is a context refresh allowed to happen at any time after an application is started? I think it is allowed to happen at any later time and this is e.g. how spring-cloud allows you to change the configuration at runtime with @RefreshScope. But when this happens a new context refresh event is sent and the onRefresh of DefaultLifecycleProcessor is called which then again triggers a CRaC checkpoint which is unwanted at this time.

I will try to create a small project which reproduces the issue.

[frederikz]

I thought the @RefreshScope from spring-cloud would lead to the second invocation of DefaultLifecycleProcessor.onRefresh but I was wrong and it was our own code were we in the ContextRefreshedEvent create a child ApplicationContext and refresh that. I have changed the code of https://github.com/frederikz/spring-boot-crac-demo to demonstrate similar behaviour. I don't know if the way we do it is to blame or if there could be more legitimate use cases that could lead to a second invocation of DefaultLifecycleProcessor.onRefresh which then would take a second CRaC checkpoint after restore.