You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Chris Colman (JIRA)" <ji...@apache.org> on 2015/01/03 22:55:34 UTC

[jira] [Comment Edited] (WICKET-5793) Request for static resource creating a session in 6.13.0+

    [ https://issues.apache.org/jira/browse/WICKET-5793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14263648#comment-14263648 ] 

Chris Colman edited comment on WICKET-5793 at 1/3/15 9:55 PM:
--------------------------------------------------------------

We have code in our override of WebApplication.newSession that we expected would not be called for static resources - and indeed wasn't up to 6.12.0 - but since 6.13.0 is. The code assumes that if newSession is called that it should perform all kinds of determination of cookies, current user, traffic statistics etc., which is all pretty much a waste of CPU and other resources when simply serving a static resource. Some of this code assumes that if newSession is being called that a Servlet session is also present.

Apache webserver is more efficient at serving static resources than a servlet container like Apache Tomcat and so I was thinking that reducing any extra processing on top of the processing that the servlet container already does when serving static resources would help make serving static resources more efficient.


was (Author: chrisc):
We have code in our override of WebApplication.newSession that we expected would not be called for static resources - and indeed wasn't up to 6.12.0 - but since 6.13.0 is. The code assumes that if newSession is called that it should perform all kinds of determination of cookies, current user, traffic statistics etc., which is all pretty much a waste of CPU and other resources when simply serving a static resource.

Apache webserver is more efficient at serving static resources than a servlet container like Apache Tomcat and so I was thinking reducing any extra processing that the servlet container already does when serving static resources would help make serving static resources more efficient in the servlet container.

> Request for static resource creating a session in 6.13.0+
> ---------------------------------------------------------
>
>                 Key: WICKET-5793
>                 URL: https://issues.apache.org/jira/browse/WICKET-5793
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 6.13.0, 6.14.0, 6.15.0, 6.16.0, 6.17.0, 6.18.0
>            Reporter: Chris Colman
>              Labels: searchengines, seo, session
>
> Up to version 6.12.0 we were not seeing any session being established when static resources were being requested - which is desirable because often search engines will hit thousands of times a day and most don't use cookies or session rewriting so we end up creating a new session for every static resource request that a search engine makes and that just blows out the number of sessions.
>  
> We use:
>     // Use message digest over resource content for resource caching
>     // cache the version information for the lifetime of the application
>     IResourceVersion resourceVersion = new CachingResourceVersion(new MessageDigestResourceVersion());
>  
>     // cache resource with a version string in the filename
>     IResourceCachingStrategy cachingStrategy =
>             new
> FilenameWithVersionResourceCachingStrategy("-ver-static-",
> resourceVersion);
>     
>     resourceSettings.setCachingStrategy(cachingStrategy);
>  
> and this worked fine up to version 6.12.0 where the code for FilenameWithVersionResourceCachingStrategy.decorateReponse was:
>  
>             /**
>              * set resource caching to maximum and set cache-visibility to 'public'
>              * 
>              * @param response
>              */
>             @Override
>             public void
> decorateResponse(AbstractResource.ResourceResponse response, IStaticCacheableResource resource)
>             {
>                         response.setCacheDurationToMaximum();
>  
> response.setCacheScope(WebResponse.CacheScope.PUBLIC);
>             }
>  
> Unfortunately in 6.13.0+ this code became:
>  
>             /**
>              * set resource caching to maximum and set cache-visibility to 'public'
>              * 
>              * @param response
>              */
>             @Override
>             public void
> decorateResponse(AbstractResource.ResourceResponse response, IStaticCacheableResource resource)
>             {
>                         String requestedVersion = RequestCycle.get().getMetaData(URL_VERSION);
> ---- >                 String calculatedVersion =
> this.resourceVersion.getVersion(resource);     < ------------
>                         if (calculatedVersion != null &&
> calculatedVersion.equals(requestedVersion))
>                         {
>  
> response.setCacheDurationToMaximum();
>  
> response.setCacheScope(WebResponse.CacheScope.PUBLIC);
>                         }
>             }
>  
> So the line marked above calls code that always creates a new session.
> You can see the stack of this scenario below:
>  
>         at
> com.sas.av.ui.wicket.templates.WicketModelExposerApplication.newSession(
> WicketModelExposerApplication.java:157)
>         at
> org.apache.wicket.Application.fetchCreateAndSetSession(Application.java:
> 1569)
>         at org.apache.wicket.Session.get(Session.java:171)
>         at
> org.apache.wicket.request.resource.PackageResource.getCurrentStyle(Packa
> geResource.java:192)
>         at
> org.apache.wicket.request.resource.PackageResource.getCacheableResourceS
> tream(PackageResource.java:398)
>         at
> org.apache.wicket.request.resource.PackageResource.getCacheKey(PackageRe
> source.java:230)
>         at
> org.apache.wicket.request.resource.caching.version.CachingResourceVersio
> n.getVersion(CachingResourceVersion.java:100)
>         at
> org.apache.wicket.request.resource.caching.FilenameWithVersionResourceCa
> chingStrategy.decorateResponse(FilenameWithVersionResourceCachingStrateg
> y.java:200)
>  
> PackageResource.getCurrentStyle() seems to be the culprit.
> Does wicket really need to create a session when a static resource is requested? 
>  
> I hope the answer is no because I think the 6.12.0 approach worked well because it did not create a new session for each static request from a search engine.
>  
> Martijn-G said in email group:
> {quote}
> It creates a temporary Wicket Session, no http session but it could be avoided.
> {quote}
> We end up doing a lot of work in the WicketSession because it is an object and it's typed and we can extend it to hold any interesting pieces we need, such as a reference to the current User object etc.,



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