[ 
https://issues.apache.org/jira/browse/STORM-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alessandro Bellina updated STORM-1890:
--------------------------------------
    Description: 
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:

$.ajaxSetup({ data: {"_ts" : "${timestamp}" } });

  was:
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:

$.ajaxSetup({ data: {"_ts" : "${timestamp}"}});


> 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
>            Priority: Minor
>
> 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:
> $.ajaxSetup({ data: {"_ts" : "${timestamp}" } });



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to