[jira] Updated: (WICKET-3194) IResourceSettings.setUseTimestampOnResources(true) and performance

["Ivan Vasilev (JIRA)" <ji...@apache.org>]

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

Ivan Vasilev updated WICKET-3194:
---------------------------------

    Attachment: quickstart.rar

Attached quickstart

> IResourceSettings.setUseTimestampOnResources(true) and performance
> ------------------------------------------------------------------
>
>                 Key: WICKET-3194
>                 URL: https://issues.apache.org/jira/browse/WICKET-3194
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.5-M3
>         Environment: Windows 7, java 1.6
>            Reporter: Ivan Vasilev
>         Attachments: quickstart.rar
>
>
> Hello, 
> I had a problem with slow loading of pages and response to ajax requests. After some debugging I traced the problem to be that wicket constantly tries: 
> DEBUG - UrlResourceStream          - cannot convert url: jar:file:/C:/Users/hok/.m2/repository/org/apache/wicket/wicket/1.5-M3/wicket-1.5-M3.jar!/org/apache/wicket/markup/html/wicket-event.js to file (URI is not hierarchical), falling back to the inputstream for polling 
> DEBUG - ResourceStreamLocator      - Attempting to locate resource 'org/apache/wicket/markup/html/wicket-event_en_US.js' on path [folders = [], webapppaths: []] 
> DEBUG - ResourceStreamLocator      - Attempting to locate resource 'org/apache/wicket/markup/html/wicket-event_en_US.js' using classloader sun.misc.Launcher$AppClassLoader@cac268 
> and this happens because that by default (or at least I think so) wicket adds timestamp on the resources - ResourceSettings.setUseTimestampOnResources(true) and every resource is read from the jar files on every request. When a resource is in a jar file a java.lang.IllegalArgumentException: URI is not hierarchical is thrown in the UrlResourceStream constructor and a lot of attempts are made to load the jar file through different loaders. In my case this led to a slow response times. 
> After disabling timestamp on resources (ResourceSettings.setUseTimestampOnResources(false)) the problem disappears and the performance is fine. However in the javadoc of setUseTimestampOnResources: 
> Enabling timestamps on resources will inject the last modification time of the resource into the filename (the name will look something like 'style-ts1282915831000.css' where the large number is the last modified date in milliseconds and '-ts' is a prefix to avoid conflicts with filenames that already contain a number before their extension. * 
> Since browsers and proxies use the filename of the resource as a cache key the changed filename will not hit the cache and the page gets rendered with the changed file.
> In this case this useful functionality is lost. Is it possible to have "the best of both worlds"? Thanks.
> This issue is raised from the discussion:
> http://apache-wicket.1842946.n4.nabble.com/IResourceSettings-setUseTimestampOnResources-true-and-performance-td3057946.html
> To observe the performance improvement, please change
> getResourceSettings().setUseTimestampOnResources(true);
> to
> getResourceSettings().setUseTimestampOnResources(false);
> in TestApplication. It's most obvious when you press Refresh All link and observe the time for the refresh in both cases

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.