You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Ivan Vasilev (JIRA)" <ji...@apache.org> on 2010/11/24 22:08:13 UTC

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

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


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.


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

Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl resolved WICKET-3194.
--------------------------------

       Resolution: Fixed
    Fix Version/s: 1.5-M4

> 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
>            Assignee: Peter Ertl
>             Fix For: 1.5-M4
>
>         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.


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

Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935575#action_12935575 ] 

Peter Ertl commented on WICKET-3194:
------------------------------------

Fixed in trunk.

The 'last modified timestamp' is now looked up just once and cached in the meta data of the current request cycle. Negative lookups (timestamp = null) are cached, too.

I also added some testing stuff for timestamped urls in the test suite.

@ivan: Your sample now runs with normal speed. Please test and reopen the issue in case something is still broken / wrong /slow / missing.




> 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
>            Assignee: Peter Ertl
>             Fix For: 1.5-M4
>
>         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.


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

Posted by "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.


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

Posted by "Peter Ertl (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Ertl reassigned WICKET-3194:
----------------------------------

    Assignee: Peter Ertl

> 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
>            Assignee: Peter Ertl
>         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.