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

["Andrea Del Bene (JIRA)" <ji...@apache.org>]

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

Andrea Del Bene commented on WICKET-5793:
-----------------------------------------

{quote}
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.,
{quote}

As Martin said this shouldn't be a problem *per se* as the lifespan of a temporary session is equal to the one of the current request (in our case the request for a static resource). Hence you shouldn't see an explosion of the number of open session. Maybe your custom Session becomes permanent by default (does it call Session#bind() ? ).

> 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)