Handleurl response.write creates multiple temporary files

Hi everyone.

Looking for help/input on a problem we encountered in web 2.0

In a nutshell:

web 2.0 seems to create a temporary file for every response sent using response.write. Since we serve between 500k and 1 million requests per day, this will fill up the servers. This was not observed with the same code in web 1.0

Question: is this normal behaviour, will the framework cleanup these files eventually, is there a call to do this, or do we have to program a hack to do the cleanup ourselves.

Additional details:

Our setup is 3 MacOS machines running 10.15, each running 8 instances of the web app (one per core). Everything is handled in the HandleURL event. This has been running in web 1.0 for a few years with very few problems. The problem appeared when we started testing the same web apps after building with Web 2.0 (Xojo 2020 r2.1) only changing the code to support the new framework.

The temporary files are created in MacOS temp files location:
/private/var/folders/ry/5h_6qwk102bcdk419k28_7b40000gn/T/_10000
Each instance has its folder which seems to be named after the listening port (_10000, _10001, _10002 …) The files contain the body of the response without headers.

To get a taste of the problem, after running 1 server with 8 instances of the web 2.0 version for about 12 hours, we have accumulated over 144,000 temporary files. So we have to address this :slight_smile:

1 Like

Is it always creating these temp files ? I can’t seem to understand why there would need to be temp files for all responses…

When I send files using request.file = myFolderitem then no, it doesn’t. For ALL other data build internally from strings and sent back using response.write, yes it does create a file for every response.

btw it’s not a typo “request.file” instead of “response.file”. Xojo allowed the web 1.0 syntax in this instance and it still works in web 2.0 although “response.file” also exists.

1 Like

This has already been addressed:

<https://xojo.com/issue/62992>

<https://xojo.com/issue/63924>

1 Like

Oh cool! Thanks. My apologies for not searching in the feedbacks. I’ll mark as resolved.

Thanks for the clarification