[Building Sakai] http expiration

Charles Severance csev at umich.edu
Mon Sep 1 05:37:40 PDT 2014


I got the idea from viewing source on the Coursera pages :)

I figured that they had some experience in scaling a single instance around the world...

/Chuck

On Aug 31, 2014, at 5:49 PM, Hedrick Charles <hedrick at rutgers.edu> wrote:

> Neat. I didn’t know about this.
> 
> On Aug 31, 2014, at 9:47:25 AM, Charles Severance <csev at umich.edu> wrote:
> 
>> Chuck - Are you talking the in-tool javascript resources or the portal?  And within tool are you talking about the head material from the portal or just generated from the markup in the tool.   For example, if I view source on the portal or schedule I see things that look like the following.
>> 
>> <script type="text/javascript" src="/library/editor/ckeditor/ckeditor.js?version="></script>
>> <script type="text/javascript" src="/library/editor/ckeditor.launch.js?version="></script>
>> 
>> Any time you see the version= it means that these assets can be (a) placed in a CDN and (b) versioned.   You can use versioning without a CDN.   If you don't see a version= it likely means the asset is being included in tool markup (not head) so it cant be versioned.  See this JIRA for details:
>> 
>> https://jira.sakaiproject.org/browse/SAK-23628
>> 
>> If you upgrade and set 
>> 
>> portal.cdn.version=12345 
>> 
>> To anything other than what it was before, every one of these files will *instantly* expire on the next refresh for every user.  My opinion is that this is a much better solution than playing with the expires header and balancing between too short so it expires quickly on upgrades and does not require lots of reloading when there are no upgrades.
>> 
>> This will be super-sweet when we have a UI to change the property value across the cluster without a reboot.  It would mean that you could click a button and within a second or two - every user would reload their copies of these core files.   Also when we have the UI you can switch these nearly-always-static assets to/from a CDN like CloudFront with a click of a button.  Pretty cool :)
>> 
>> /Chuck
>> 
>> On Aug 28, 2014, at 3:07 PM, Charles Hedrick <hedrick at rutgers.edu> wrote:
>> 
>>> library, portal and calendar use a filter to set max-age to a month. Other tools don’t do anything, which results in a random but long time.
>>> 
>>> Every time we update sakai we have a period of weeks when people’s results are broken because of our of data Javascript.
>>> 
>>> I think a month is too long. With modern browsers when the cache expires they just check. They won’t fetch the file if it hasn’t changed. I think a day makes more sense. Furthemore, it has to apply to .js files in the tools, not just library.
>>> 
>>> I propose using the tomcat or java expires filter to set a one-day expiration for all files of type javascript.
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140901/9b68a672/attachment.html 


More information about the sakai-dev mailing list