Descriptive Problem Summary:
When running multiple instances of a game that outputs any browser content, closing one instance would clear the cache that the other instance was using. This instantly breaks pages being viewed that used hyperlinks or any resources such as images that were pre-cached.
Numbered Steps to Reproduce Problem:
1. Run two instances of a game that outputs a browser form, or uses browse_rsc().
2. Close one instance, and the other instance will not be able to access those files (as the closed instance would have cleared the cache data)
Expected Results:
The cache should only clear when all instances are closed.
Actual Results:
The cache is cleared when any instance is closed.
Does the problem occur:
Every time? Or how often? Every time.
In other games? Yes.
In other user accounts? Yes.
On other computers? Yes.
When does the problem NOT occur?
Usually this problem won't occur if the game sends all needed data before.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
This problem probably didn't exist before the recent feature of cache clearing was implemented, although I haven't tested it.
Workarounds:
Send all data that the browser interface will use before displaying it. This won't always work, since some browser interfaces exist for prolonged periods and another instance closing would break that page.
ID:80364
 Aug 25 2009, 3:27 pm
|
|||||||||||
Resolved
| |||||||||||
In the next release, if you assign a filename to the cached item (so it can be referenced later), the cache will store it for a while instead of deleting it after the session.
| |
If I understand correctly, wouldn't this fix still break old games? I would think that having the cache clear after all instances were closed would make much more sense in that programmers wouldn't have to change their code just to prevent this from happening.
| |
Well, keeping cached files around doesn't really hurt outside of eating up extra disk. In some cases we actually want the files to last beyond the session (even after all sessions are closed), such as the saved pager news (so the last news will appear even if you are offline the next time you bootup).
Your case is a very special situation where the same file is used between two running instances (I can't imagine this comes up much). I think that caching those files for even a day after last modification effectively resolves the problem (at the moment it saves for 7, which has to be more than enough). Your solution is more comprehensive but it does take a bit more work. I don't think it'll matter to the end user or programmer one way or the other. It occurs to me that we also have to save cached sound files, which use an autogenerated name, since those are later referenced. | |
Just to be clear, I don't mean to imply that programmers have to change any code for this to work. The problem is happening mainly with files cached under an assigned name, since those are the ones referenced later. Those files will now be stored for some time, avoiding the multiple instance problem. Sound files (given an autogenerated name) will also be saved longer. I don't think any other autogenerated files can be referenced without being regenerated, so those are safe to delete per session.
| |
Ah, well I was about to post a long response but I guess you answered that question.
In my situation, the browser output is identical and never changes, and I'm guessing the autogenerated name is a hash, so it would indeed use the same file name. Would this still be an issue? In my situation, that one browser interface is a quick fix, but the main issue I was having with this bug was involving browse_rsc() files being deleted right after (as I don't want to send the same data every time I output to a browser control that uses the resources) | |
Yeah, the system is kind of stupid at the moment because it regenerates the file everytime you browse() to it, whether it exists or not. So it's not a real cache. Maybe we'll fix that eventually but I think the overhead of writing the file is negligible.
The only time the cache files are used without being overwritten are (AFAIK): 1) when you manually reference a cache file in a browse() call (eg, to reference an image uploaded with browse_rsc() through an IMG tag). In this case you will have to assign the filename and those files are now kept for 7 days from their latest modification (so if you keep accessing them they'll cache indefinitely). 2) with sounds, which pass the autogenerated filename to the FMOD system. I don't know if FMOD caches these separately, but if not, in the current release if you run two instances and reference the same sound, and then close the first instance, it'll probably fail to replay that sound in the second instance. Both of these cases should be fixed in 455. | |
You can workaround this by passing filenames to browse() instead of relying on the auto-generated names. Manually assigned files get cached for a longer period.[er maybe not]