[
https://issues.apache.org/jira/browse/WICKET-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036391#comment-13036391
]
Martin Grigorov commented on WICKET-3730:
-----------------------------------------
Another thing that slows down is
org.apache.wicket.settings.def.ResourceSettings.getResourceStreamLocator().
It caches only in DEPLOYMENT mode.
> extremely slow performance in development mode
> ----------------------------------------------
>
> Key: WICKET-3730
> URL: https://issues.apache.org/jira/browse/WICKET-3730
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 1.5-RC4
> Environment: OS X, java 1.6
> Reporter: Konstantin Ignatyev
> Assignee: Peter Ertl
> Fix For: 1.5-RC1
>
>
> I just finished migrating application to 1.5 and it became VERY unresponsive
> and slow in development mode. In -deployment- it is OK.
> No changes were made to backend services, only necessary Wicket API use
> changes related to request cycle.
> =======================
> Below is the originals bug: WICKET-3194
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
