Uploading application/zip to styles endpoint does not clean up temporary files
Description
The environmental variable java.io.tmpdir is mapped to a temporary filesystem; which gradually fills up over time with temporary files.
On closer examination the files are of the form:
1658326181341-0/rain.sld
1658326181324-0/detail.sld
1658326181324-0/detail8.png
1658326181324-0/detail44.png
I expect that the /workspaces/{workspace}/styles endpoint is being used to upload application/zip, extracting the results to the java.io.tmpdir and not marking the individual files for deletion with File.deleteOnExit().
Environment
Linux
Activity
Show:
Andrea Aime August 4, 2022 at 8:20 AM
Processes do not use a thread local clean up, there is a cleaner that eliminates the directories that are too old (we don’t know when the client is going to ask for the results, in a asynch request, so the mechanism is time based).
As said, if it’s a temp file, it should be just tracked and removed explicitly before the end of the request, rather than depending on a “garbage collection” mechanism.
Jody Garnett August 4, 2022 at 8:06 AM
Edited
Was only thinking of deleteOnExit() because they were “temp” files.
Some kind of thread local cleanup as with processes?
Andrea Aime August 4, 2022 at 7:55 AM
But… why “on exit”? A GeoServer can be up and running for months at a time. If those are actual temporary files shouldn’t they be removed by the time the REST call is complete?
The environmental variable
java.io.tmpdiris mapped to a temporary filesystem; which gradually fills up over time with temporary files.On closer examination the files are of the form:
1658326181341-0/rain.sld1658326181324-0/detail.sld1658326181324-0/detail8.png1658326181324-0/detail44.pngI expect that the
/workspaces/{workspace}/stylesendpoint is being used to uploadapplication/zip, extracting the results to the java.io.tmpdir and not marking the individual files for deletion withFile.deleteOnExit().