[
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15409891#comment-15409891
]
ASF GitHub Bot commented on STORM-1890:
---------------------------------------
GitHub user abellina opened a pull request:
https://github.com/apache/storm/pull/1612
STORM-1890: looks like too many calls were moved to getStatic
Reverting some of the changes I made in:
https://github.com/apache/storm/pull/1536
What is on master shouldn't break requests, but it is sloppy, so this
should clean up. I didn't create a new JIRA but can if appropriate. Will PR for
1.x and 0.10.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/abellina/storm
STORM-1890_remove_unnecessary_calls_to_getStatic
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/storm/pull/1612.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1612
----
commit 3c9e27b94bcc69a95ee921b9b0837c178dfaed5b
Author: Alessandro Bellina <abell...@yahoo-inc.com>
Date: 2016-07-28T03:37:40Z
STORM-1890: looks like too many calls were moved to getStatic. It doesnt
break things, but it is sloppy, so reverting some to $.get
----
> Employ cache-busting method to ensure newly deployed UI forces browsers to
> refetch scripts, templates, and CSS
> --------------------------------------------------------------------------------------------------------------
>
> Key: STORM-1890
> URL: https://issues.apache.org/jira/browse/STORM-1890
> Project: Apache Storm
> Issue Type: Improvement
> Components: storm-ui
> Affects Versions: 2.0.0, 1.1.0
> Reporter: Alessandro Bellina
> Assignee: Alessandro Bellina
> Priority: Minor
> Fix For: 2.0.0, 1.0.2, 1.1.0
>
>
> Currently we don't employ cache busting techniques in the Storm UI while
> fetching script.js, CSS and templates. Ring is providing the Last-Modified
> header, but browsers implement a heuristic to when they deem a resource stale
> (https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.2.4). This
> means that as the Last-Modified for a resource is further away in the past,
> the longer the browsers are going to wait until they refetch. It looks like
> 10% padding is common, so if script.js was last modified 100 days ago, the
> browser will not fetch it until 10 days after the time it was cached.
> An easy approach is to add a url parameter to allow for cache busting
> whenever storm is packaged (mvn package). A more complicated method is
> versioning the files (we'd need to specify them in the pom.xml individually
> using the assembly plugin, unless we use some other plugin). The first method
> is (was?) considered less effective, since some CDNs/browsers can decide not
> to cache the query parameter.
> I'd like to go with the simpler method, unless there are strong opinions to
> changing file names (this means we need to specify files in the assembly
> pom.xml). Also, going this route we don't need any new plugins, and the
> assembly build can just be changed to export a variable. We would modify
> calls to include a value that changes on mvn package:
> {code}
> <script src="/js/script.js?_ts=${timestamp}" type="text/javascript"></script>
> {code}
> instead of:
> {code}
> <script src="/js/script.js" type="text/javascript"></script>
> {code}
> Where $\{timestamp\} will be replaced at assembly time by maven. This would
> be the time when the assembly build started.
> The templates will also have the extra parameter. I think providing this to
> ajaxSetup will do the trick. For example:
> {code}
> $.ajaxSetup({ data: {"_ts" : "${timestamp}"}});
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
