Gzipped js files in 12.1 in production

[mathias]

We're currently looking at upgrading from our current 6.0 -> 12.1. One new thing for us, it seems, are .gz files.

I found another thread here where you recommended using the FileDownloadServlet, however in the web.xml you recommend using Apache for this in prod. We do run with Apache infront of Tomcat, but i'm not sure i'll have time figuring out the setup for that.

I was thinking that i'd only use it for the ISC javascript files in production, you see any issues with that? What would you recommend?

[Isomorphic]

Those have been there since the first release :)

Our recommendation is to do what the docs say..

Streaming files in Java is not efficient and with Apache in front, Apache is doing more work to stream the file from Java that if it just sent it directly.

[mathias]

Really? They're not there when i build the project with 6.0, but they started appearing now in 12.1, that's how i noticed them. but ok if you say so! :)

[mathias]

Hi, i got the FileDownload servlet up and running on my Tomcat. Works great, just have a few questions though.

1. I have configured the servlet to also handle the cache.js and nocache.js GWT files. I have read that one should not cache the nocache.js at all, but i'm not sure what the big deal would be to set a 2h timeout just like all other javascript files?

2. I noticed that you don't have a .gz version of load_skin.js in your skin dirs. Is there a reason for this? Was thinking of compressing my custom skin.

[Blama]

mathias,
that would break your application for up to two hours, as the content of the nocache file (basically the filesname per permutation) changes with every compile.
People with that file in cache would then not see your new version for up to two hours or perhaps even see nothing if they don’t have the big permutation.js file already in their cache.

Best regards
Blama

[Blama]

With this and version-cache breakers for the framework-js files you can by the way cache all files basically forever.
my 2nd load consists out of nocache and 3 Ajax calls - all the rest (also DataSourceLoader) can be cached.

[mathias]

Yeah. My thinking was that 2 hours is not such a big deal, but you're right, they don't see the old version, basically everything breaks... Would be nice if the FileDownload servlet could somehow exclude just the .nocache.-file.

With version-cache-breakers i suppose you mean stuff like the Tuckey URLRewriteFilter? I use it only to break the cache on my load_skin.js and css for some reason. It was ages since i set this up so i don't even remember why. I suppose i could set it up for the nocache too.

How long do you cache the other js files? Do you have cachebreakers for all files? i have 2 hours for all js.

[Isomorphic]

It's fine to deliver load_skin.js gzipped.

GWT nocache.js can be cached for a short amount of time if you don't care about the delay before users would see a new version of your application.

DataSourceLoader results cannot be cached because they can differ by user or user role. Even individual but not shared caching is not really safe, since it would prevent an end user from acquiring new roles.

[mathias]

Exactly, that's why we cannot cache DataSourceLoader, our users can become admins, lose priviledges etc. We load different datasources depending on role and other things.