Cache oddity (15 character title madness)


#1

@chris

It seems odd that an item deleted from web server (with intent) would continue to be rendered in scene - interface indicates file is missing on remote server, using cached copy. I, for one, do not think this is desired behavior - if I’ve deleted an item from server, I expect it to be gone in scene even if I didn’t delete it in scene via interface. Since interface is getting a 404 it knows proper response is item no longer exists (thus the error message in debug). If Interface couldn’t reach asset holding server then I could see it using cached copy.

Another item - minor. Interface previously went into an idle mode when its window wasn’t active – idling down to render rate of 15(ish) FPS. Currently on Windows and Linux with latest code it continues to render at full rate regardless of window being active or minimized.


#2

There’s one problem. can you really see the difference between 404 or server down ? the both generate possible at the end a 404. So if the object cannot be loaded. don;t show it. Or betetr replace it for some dummy object or something else so you know there’s a problem.

Mabye create a warning on the stack maanger administrator console ?


#3

Time out due to server outage will generate a timeout. To get a 404 server has to send it back, thus server is responsive.


#4

@Richardus.Raymaker , The domain manager et-al need to and hopefully are HTTP status code and cache management compliant. A 404 is a status response to an http(s) request. A 404 means resource is not present. Now the problem that @OmegaHeron reports is different. Once something is cached there would not be any requests sent to a server for that particular resource, because, well, it is cached! So the issue here is about lifetime management, and there are standards to manage caches. There are cache lifetime management headers that can be sent along with responses to resource requests. For example, your asset server could send a cache-this-for-one-day header and the client is expected to follow that directive. Then when the resource is taken down eventually the caches clear up.

There are other status codes that need to be observed, especially the temporary and permanent redirection ones.


#5

I have to admit I’m more concerned about case where a mesh that crashes Interface is placed. I’d rather delete the offending mesh and be able to log in vs having to juggle stack side incremental backups or wait for cache to time out. But - yes, if HTTP asset requests is going to continue on, then, by all means, it should honor all returns - in case of a 404 I suggested via worklist, a very long time ago, that a pre-made mesh be rezzed as a error marker. As with most things there, nothing came of it.


#6

That got fixed. There is now a clear all caches command. See menu View/Reload Content (soon to be Develop/Reload Content).


#7

You can’t clear it if you rez into a domain that instant crashes you before you can clear cache. But - that’s just an example of another reason an entity that’s been deleted from [whatever it will be type] asset server shouldn’t lead to said entity being placed in scene from cache. It’s easy enough to blow out cache manually or shuffle server side files when need be, with point being, you shouldn’t have to do any of that.

The clear cache command has been around forever as has the issue with things being placed in scene that, likely, shouldn’t. I just crawl from under my rock every few months to bring it up again in the hopes it may, someday, warrant some attention. Having done so - back to my bunker. : )