ICEfaces
  1. ICEfaces
  2. ICE-2519

Session access in portlets via Ajax does not change portlet session lastAccessedTime

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.7RC1, 1.7
    • Component/s: None
    • Labels:
      None
    • Environment:
      Portal portlet, Liferay portal, JBoss portal.

      Description

      It appears that, at least in the case of Liferay, that ICEfaces' Ajax communication has an adverse side effect when accessing the session. The Ajax requests generated by ICEfaces currently go directly to our own framework servlets (rather than through the portal container). Because the portal container never sees the Ajax requests, the lastAccessedTime of the session is never updated. The result is that, even though a user may continuously interact with a portlet, the session can timeout after the configured time.

        Issue Links

          Activity

          Hide
          Deryk Sinotte added a comment -

          Need to support doing our Ajax communication through the portal container.

          Show
          Deryk Sinotte added a comment - Need to support doing our Ajax communication through the portal container.
          Hide
          Ken Fyten added a comment -

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

          Show
          Ken Fyten added a comment - This issue also occurs with JBoss Portal. Likely affects all portal containers.
          Hide
          Deryk Sinotte added a comment -

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

          { Session internalSession = request.getSessionInternal(); internalSession.access(); }

          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.

          Show
          Deryk Sinotte added a comment - 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")) { Session internalSession = request.getSessionInternal(); internalSession.access(); } 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.
          Hide
          Deryk Sinotte added a comment -

          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>

          Show
          Deryk Sinotte added a comment - 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>
          Hide
          Deryk Sinotte added a comment -

          Change is checked in. Resolving as fixed.

          Show
          Deryk Sinotte added a comment - Change is checked in. Resolving as fixed.
          Hide
          Jesper Tejlgaard Pedersen added a comment -

          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
          Show
          Jesper Tejlgaard Pedersen added a comment - 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

            People

            • Assignee:
              Unassigned
              Reporter:
              Deryk Sinotte
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: