Chart files in Temp directory not being deleted

[Jeff]

We have a behavior on our production and UA instances where the charting temp files are not being deleted.  When I attempt to duplicate this on my local and QA instances I see the files being created when I generate a chart but then promptly removed.  However on our other public sites these files are not being deleted.

The directory is ...\OurWebsite\Temp\
The files are named like "chart_19219c2e...a352.png"
The files date back to 3/1/2013 
The telerik version is 2012.03.1017.0

Our first thought was security.  The application pool is using a specific system user.  This system user has full control of the website directory including delete permission on the Temp directory.

• Can the details of the process using these temp files be explained in hopes of helping where to check next?
• How are these files automatically deleted, what is the trigger?
• Are there known reasons that the files would not be deleted?
• Are there logs to capture the delete errors?  No errors are being raised by the application, we found out when we ran out of space.

Thanks for the help on this one.

-Tim

[Petar Kirov]

Hi Tim,

The ASP.NET AJAX RadChart works like this:
1. When the page containing the control is created, a chart image is rendered and saved on the disk / in the session.

2. The server sends an HTML document containing an img tag which has a source attribute set to something like "ChartImage.axd?ChartID=bd6589b0...".

3. When the client browser process this tag it requests the image from the server.

4. Next on the server the Chart Image HttpHandler is activated and tries to load this image from the disk/session. After it loads it it writes it in the HttpContext.Response. 

5. The Chart Image HttpHandler tries to delete the image from the disk / session.

That said, the main suspect is the security policy on the TempImages folder, however from your post this doesn't seam to be the case.

Another case - a bit more complicated may be the following:
1) The chart control gets loaded and rendered (thus generating the image file).
2) However, the browser has turn off the option to load images, or some plugin is blocking the download.
3) As a consequence from (2) the HTTP Handler never loads up and never deletes the image from disk.

If the problem persists I suggest that you do one of the following:
1. Create your own daemon application that periodically deletes all the images in the folder older than eg. 5 minutes. 

2. Write a custom HttpHandler and implement a custom strategy for handling these problems.This might be helpful, because you can log every step process, so you can more easily troubleshoot later if it is needed.

I hope this helps.

Regards,

Petar Kirov
Telerik

[Jeff]

Thank you.  Your response is exactly what the team wanted.  

We leveraged this information and was able to isolate how to reproduce this.  --Refresh--.

If the user refreshes the page over and over again, just pressing F5 repeatedly or re-navigating to it before the page is allowed render will leave the un-fetched image files in the directory.  We will likely put something in our install process to clear this directory during upgrades.

Thank you again.