jmfield2
commented
7 years ago Note that this perhaps may not have anything to do with the netscaler since mobullity also seems to have similar issues with caching.
Also, some assets (images), and the POI system in particular seem to insist on being served from local cache despite a ctrl-f5 refresh.. We might need to do more robust handling of the cache headers here (like check the date the graph was built) and serve a 304 not modified response instead of always a 200 ok.
barbeau
Summary:
Since we added a cache-control header to static assets (JS, etc) served by Grizzly, it seems like it is more problematic to redeploy mobullity without issues on the client-side where old files are used instead of newer files.
Steps to reproduce:
Load the website after it is redeployed and note that sometimes a forced refresh is required before the new assets are served.
Expected behavior:
New assets should be served in accordance with the "If-Modified-Since" headers sent.
It seems like this isn't happening because the netbalancer has no way to know (?) that the content has changed since max-age hasn't elapsed.
Other than somehow invalidating the cache with the balancer, other solutions might be:
1) Use cache-control: must-revalidate (in case it isn't the default in our case) 2) Lower the max-age from the current 604800 seconds (1 week) to something less like 1 day 3) Add ?param (like a version number) cache-busters to the URL of static assets upon deployments. 4) Disable serving cached assets @ netbalancer if possible
Observed behavior:
Static assets are served despite having been changed upstream. This is likely the result of the netbalancer not invalidating the cache since it doesn't actually know the content changed.
In my local testing redeploying the Java webapp does seem to handle the if-modified-since header correctly and responds with a 200 OK response for changed assets. (Observe that a 200 is followed by a 304 and then a 200 after redeploying)
Platform:
Java 1.8 Linux, Firefox, Chrome