I don't know your specific issue. but be aware that CF intercepts the calls to make the png with a CFFileServlet mapping. It has a path similar to "www.yoursite.com/CFFileServlet/_cf_chart/4645338000104712.png". Just make sure the /CFFileServlet isn't being blocked someplace. Also in the CF Administrator, there are settings for cfchart under Server Settings -> Charting. Try using Cache Type: Memory. Also try increasing the Time-To-Live.
Thank you so much. It looks like by changing the setting, it's working.
That probably means that the mapping to the disk cache doesn't exist or that the user associated to the coldfusion services does not have write access to it. But unless you are generating a lot of long lived charts or short on memory, I'd stick with saving them in memory anyway.
I just started using CF12, upgrading from CF10. I noticed that there may be a memory leak related to using. Settings -> Charting -> Cache Type: Memory.
If you notice that your memory is higher and going up, you may need to set it back to disk. I had to set mine to disk to avoid the memory leak. I hate that they moved to zingchart in CF11, and the memory issue I'm seeing is related. I also noticed that I can't change the Chart Cache Path, so I have to live with the default. Even when I set it through the Admin API and the neo-graphing.xml file, it's still using and stuck in the "...\instance\tmpCache\CFFileServlet\_cf_chart" directory. Interestingly, they seem to be using eHcache to manage the chart caching.
I'm going to try to reproduce the memory leak and submit it as a bug, along with the Chart Cache Path issue. I'm using jProfiler to track down the leak.
When I was looking into this, I realized CF is using Ehcache to cache cfcharts. This is true for both in-memory and disk. They must also be using the timeToLiveSeconds attribute for the expiration and this maps to time-to-live in the CF Admin. I noticed that this attribute was not working for us in CF10 and now CF12. We didn't have a need for it in CF10, so I ignored it. I think this issue might be specific to our setup, I'll need to look into that. So although its a type of memory leak, its just that Ehcache is not expiring the charts in the cache, so they just keep growing. Oddly the time-to-live appears to work when caching to disk.
If anyone else has an issue with timeToLiveSeconds working in Ehcache, let me know and save me some time tracking it down.
Back to your original issue and something I came across while looking into my Ehcache issue. There is a mapping in web.xml for "CFFileServlet". This is what intercepts the URL call for charts. If you happen to have a URLRewite rule someplace that rewrites URL's to lowercase, then the call to the chart image will all be lower case and not camel case. Having a lowercase URLRewrite rule is common for web apps and SEO optimization. This will cause a 404 when the url "/cffileservlet/_cf_chart/001234.png" is lowercase. If you have the lowercase rule, you'd need to add a mapping for "CFFileServlet" for the lower case call.
<!--- specific to camel case mapping --->
<!--- needed to support lowercase --->