RFR: JDK-8213214: Set -Djava.io.tmpdir= when running tests

[Sergey Bylokhov]

On 6/17/20 6:11 am, Erik Joelsson wrote:
> On 2020-06-16 23:25, Sergey Bylokhov wrote:
>> As far as I understand this new temp folder will be cleaned after every
>> tests run, doesn't it look like a workaround for problematic tests and
>> product bugs?
> This new tmp folder is created in the jtreg test-support dir (which is where we direct the jtreg work dir). It's global for one invocation of jtreg. This work dir is cleaned and recreated before a test is run from the makefiles. In the local developer case, this means it will stay around until you run the same set of tests again, manually delete it, or you run "make clean". In a distributed test environment, it will stay around until the distributed system decided to clean up the test workspace. Like for any artifact created by tests, this is exactly what we want.
>> Personally, I found many bugs in the tests and some product bugs as
>> well, which caused "leakage" of the temporary files.
>>
> If tests are allowed to write files anywhere outside of the test workspace, then they will eventually leak those files, regardless of how well implemented the test is, because tests can fail and crash. If tests couldn't fail, there would be no reason to run them. When running millions of tests every day, those failures add up and fill up disks.

Some other applications or the system itself may crash as well, so such workaround will not solve the problem of the trash in the temp folder, you will need to periodically clean up this folder anyways, isn't it? BTW it is also necessary to cleanup the trash as well.

>> Probably additionally to this fix we should personalise every temp
>> file created in the test context via createTempFile or similar API and
>> report the test as failed if the file was not removed at the end?
>>
> In my opinion, there is very rarely a reason to use createTempFile in a test. When trying to investigate a failed test, I always much prefer tests that create explicit files in an assigned sandbox/workdir and leaving them behind for later inspection. I rather employ a clean first strategy (as we do with the workdir from the makefiles), where the test is aware that a previous run may have left files around in the known locations and deletes them first. As long as these files aren't adding up to outrageous amounts of data of course.

This createTempFile is not necessarily used by the test directly, it might be used by the code in JDK, which is triggered by the test.

I remember that the infra team reported tens of different bugs in the client tests and jdk itself, so it will be good to track/report this somehow.
Just an idea to set tmp dir per test via the jtreg, and report test as suspicious / failed if the folder is not empty.

-- 
Best regards, Sergey.