Let's stop calling it "lifecycle managed" as that suggests our app management actually has anything to do with it. It's all about the out-of-memory killer and how it behaves. It will just kill one process that it sees fit to kill (in this case, the renderer), so the *app*, being the webapp container, lives on. So there's no screenshot, per se, it's all the app still working (but SIGSTOP'ed, suspended). Once you focus it, it realizes it lost the renderer and the web canvas goes blank (totally blank if webapp has no header, header still around if it was there in the first place).
There's two potential solutions here:
a) get OOM to kill the whole pgroup
b) make the webapp container recover by restarting its renderer
a) would be more in line with our overall lifecycle management
b) could be quicker, as we only need to start the renderer, not the whole app, but the shell won't have control over how the recovery looks
Let's stop calling it "lifecycle managed" as that suggests our app management actually has anything to do with it. It's all about the out-of-memory killer and how it behaves. It will just kill one process that it sees fit to kill (in this case, the renderer), so the *app*, being the webapp container, lives on. So there's no screenshot, per se, it's all the app still working (but SIGSTOP'ed, suspended). Once you focus it, it realizes it lost the renderer and the web canvas goes blank (totally blank if webapp has no header, header still around if it was there in the first place).
There's two potential solutions here:
a) get OOM to kill the whole pgroup
b) make the webapp container recover by restarting its renderer
a) would be more in line with our overall lifecycle management
b) could be quicker, as we only need to start the renderer, not the whole app, but the shell won't have control over how the recovery looks