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 2014/12/23 22:50:13 UTC

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

Chris Colman created WICKET-5793:
------------------------------------

             Summary: 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.18.0, 6.17.0, 6.16.0, 6.15.0, 6.14.0, 6.13.0
            Reporter: Chris Colman


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)