This issue also occurs with JBoss Portal. Likely affects all portal containers.

A potential workaround for portals that run in a Tomcat environment is to use a Valve to touch the session during client-initiated requests. To do this:

1) Create a Valve that does the same as the following:

package com.icesoft.faces.webapp.http.portlet;

import org.apache.catalina.valves.ValveBase;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.Session;

import javax.servlet.ServletException;
import java.io.IOException;

public class TouchSessionValve extends ValveBase {

public void invoke(Request request, Response response) throws IOException, ServletException {
String reqURI = request.getRequestURI();

if( reqURI.endsWith("send-receive-updates"))

getNext().invoke(request,response);
}
}

2) Compile this (it depends on catalina.jar) and build it into a jar (e.g. icefaces-portlet-valve.jar) and put the jar into Tomcat's set of server libraries:

[tomcat-root]/server/lib/icefaces-portlet-valve.jar

You'll need to restart Tomcat for this to take effect.

3) Add a META-INF/context.xml file to your portlet archive. The contents of the context.xml file should look like this (match the fully qualified name to the Valve class you created):

<Context>
<Valve className="com.icesoft.faces.webapp.http.portlet.TouchSessionValve" />
</Context>

Now when you deploy and run your portlet application, each user-initiated request will "touch" the session and ensure that it doesn't expire prematurely.

I've checked in a more general solution to this problem. Basically, we increase the maxInactiveInterval (aka the session timeout value) with each client initiated request. The calculations are always based on the lastAccessed time so if the page is reloaded for some reason (adding a portlet dynamically, hitting the reload button) the maxInactiveInterval gets returned to its original value. The solution should also be harmless if the Valve mechanism described previously is also being used (although it's not necessary to use both).

The fix is "on" by default but can be disabled by setting the following context parameter in the web.xml file:

<context-param>
<param-name>com.icesoft.faces.adjustPortletSessionInactiveInterval</param-name>
<param-value>false</param-value>
</context-param>

Change is checked in. Resolving as fixed.

Seems it does not work for Websphere Portal. It seems that Websphere Portal uses two sessions

• the portal session for the whole portal server
• and the portlet session for a specific portlet.
  The above solution seems to only extend the portlet session. We unfortunately had use cases where the Portal Session timed out. I only managed to find a solution, by creating a dummy Portlet, which we could ping upon Ajax requests. A better solution would have been preferred though. See more here: http://jespertejlgaard.blogspot.com/2011/10/workaround-to-session-timeouts-in.html