Graceful exit for cleanup of temporary folders

[eliasbalasis]

I have noticed temporary files and folders created during "DevMode" and "codeserver" execution, which are never deleted because there is no way to exit the running process gracefully.

Some of the folders seem to be generated by "codeserver" , some others by the GWT compiler , some others by Jetty, etc.

There is also possibility for more temporary folders being be created by custom DevMode launchers, leading to even greater waste of space.

Theoretically, GWT should be cleaning these folders on JVM exit and could be perhaps accepting a graceful termination signal from GWT Plugin to do so.

Would such a feature be desirable ?

see also gwt-plugins/gwt-eclipse-plugin#512

[tbroyer]

IIRC, the problem is about "others" sending a graceful termination signal to the JVM so the shutdown hooks (either explicit, or implicit from createTempFile/createTempDirectory) are properly executed. There's hardly anything to be done on GWT's side, the problem is on Eclipse's side and/or Windows' side that do a "hard kill" (in POSIX terms, they do a SIGKILL rather than SIGTERM or SIGINT).
I have a similar problem in the gwt-maven-plugin where killing the Maven process leaves the GWT process orphan (but running): tbroyer/gwt-maven-plugin#110

One proposed solution was to add a TCP listener on some port so another process could ask it to exit "remotely", similar to Jetty's stop port and stop key: https://jetty.org/docs/jetty/12/operations-guide/start/index.html#stop-remote

I'm not a fan because that's a workaround for an external, unrelated issue.

[eliasbalasis]

Good point @tbroyer

I understand the process termination signal complications.

I am guessing this would have to take the form of a custom GWT mechanism then, which I appreciate can be demanding.

It is not an essential function but if it is desirable we could perhaps consider implementing it in the future, when priorities permit.

[niloc132]

I think we should close this from the GWT side - any process that isn't permitted to shut down properly can't deal with its deleted files, but the fault for that has to lie with the calling code that forced the shutdown in this way.

With that said, you're asking about some custom GWT mechanism - what exactly do you have in mind? We could gather all the process resources into one Runnable (both as a shutdown hook and exposed so downstream projects could customize shutdown behavior. Other "temporary" things like running compiles might need to be held somewhere accessible too so they can be canceled, and their resources cleaned up. In terms of a mechanism, exposing a stop port could be an option, or like tomcat/jboss we could have a jmx command set up?

Or is it possible to just extend DevMode and run a sliver of code that will allow easy reach from the rest of the eclipse plugin to directly invoke System.exit()?

What is Eclipse doing for other processes (other than Jetty) that have files to clean up? I can't imagine that every vertx/quarkus/springboot/etc application binds to a port to be told that it should clean up resources and prepare to go away?

[eliasbalasis]

I would vote for extending DevMode with cleanup code in a shutdown hook.

However, the GWT Plugin would also have to be extended with a mechanism to trigger a graceful termination of DevMode instead of a violent one.

A stop port sounds interesting and closer to what I had in mind.

What is Eclipse doing for other processes (other than Jetty) that have files to clean up?

Good point.
I wondered the same.
I am guessing Eclipse is doing something special, triggering a graceful termination, instead of a violent one.
Perhaps we could use similar in GWT plugin, instead of a stop port (or other mechanisms).

[niloc132]

I would vote for extending DevMode with cleanup code in a shutdown hook.

GWT DevMode (and Compiler, etc) already has a shutdown hook to cleanup, unless I am misunderstanding exactly what you want to have cleaned up - maybe provide a specific example?

You can tell the shutdown hook is there because when these processes exist safely (or with an error, but not when killed instantly with no chance to clean up), the files are cleaned up. A few are not, by design - the compiler output, extras, and the unit cache, ideally these are placed in a directory owned by whatever the next level up of build system exists, so it can clean caches, etc.

That's why our takeaway here is "the Eclipse tooling is at fault, and needs to stop killing the process without a chance to finish the existing shutdown hooks". But if you have a counterexample not caused by Eclipse (and windows?), we should investigate.

[eliasbalasis]

That's why our takeaway here is "the Eclipse tooling is at fault, and needs to stop killing the process without a chance to finish the existing shutdown hooks". But if you have a counterexample not caused by Eclipse (and windows?), we should investigate.

I am describing the same.
My understanding is that the tooling is primarily at fault.
It seems to be killing the process violently indeed, not giving chance to finish gracefully.