Portlet Caching

uPortal supports all of the JSR-168 and JSR-286 caching features.

Expiration Based Caching

Portlets can specify an expiration timeout, in seconds, in their portlet.xml or via a response property or via the CacheControl API. When an expiration time is set the portal will return the cached content for the portlet until the expiration time passes OR until the user directly interacts with the portlet.

Validation (ETag) Caching

Portlets can specify an ETag along with expiration time on render and resource responses which are used to represent the state of the response. Subsequent requests with the ETag and the portlet can simply respond that the cached content is still good. Validation caching also allows the portlet to mark specific responses as public or private scoped, publicly scoped data may be shared between multiple users.

uPortal takes these ETag related features as far as possible to improve performance with resource responses getting the biggest benefit.

When a portlet sets an ETag on any response with an expiration time the portal caches the content using the ETag, until the expiration time passes any subsequent request for the same ETag results in immediate replay from cache
One the expiration time for an ETagged response has passed the portlet is consulted to see if the ETag is still valid for the request, if the portlet returns true the content is replayed and the cache expiration updated.
On resource responses the ETag is passed to the browser as the ETag HTTP header

Chrome has some caching issues when using eTags with ResourceRequests (subsequent eTag hits return empty response from cache). See the latest CalendarPortlet code for methods of overcoming this. (Jan 2014)

More Information

For a complete description of how portlet caching works it is recommended to read section PLT.22 of the JSR-286 specification.

Caching of static assets

uPortal and some portlets are configured to cache static assets such as *.js and *.css configuration in web.xml, a spring context file, and ehcache.xml, for example.

web.xml

<filter>
    <filter-name>pageCachingFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    <init-param>
        <param-name>targetFilterLifecycle</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>
    
<filter-mapping>
    <filter-name>pageCachingFilter</filter-name>
    <url-pattern>*.js</url-pattern>
    <url-pattern>*.css</url-pattern>
</filter-mapping>

Other configuration is needed in applicationContext.xml and ehcache.xml, and you typically also use a cacheExpiresFilter See the following for examples:

This can be a pain when doing local development because changes to JavaScript or CSS files require restarting Tomcat or other procedures to clear the spring-managed page cache. In these cases one solution to speed development and allow you to see changes to static resources immediately is to temporarily comment out the url pattern from the filter-mapping (but don't check it in).