[
https://issues.apache.org/jira/browse/WICKET-3730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Ignatyev updated WICKET-3730:
----------------------------------------
Description:
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:
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
was:
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
Environment: OS X, java 1.6 (was: Windows 7, java 1.6)
Affects Version/s: (was: 1.5-M3)
1.5-RC4
> 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:
> 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
