ICEfaces
  1. ICEfaces
  2. ICE-4275

Bridge incorrectly states Session Expiry when loading/reloading/redirect navigating

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.8RC2
    • Fix Version/s: 1.8
    • Component/s: Bridge
    • Labels:
      None
    • Environment:
      IE7, FF3

      Description

      There seems to be some kind of timing issue when the bridge is being loaded / reloaded in certain circumstances that results in the the bridge indicating that the Session Expired, incorrectly.

      Difficult to reproduce, we have several user reports of this occurring in the applications during redirect navigation.


        Activity

        Hide
        Stefano Bortoli added a comment -

        In my case the problem exists also with icefaces 1.7.2SP1.
        The loading problem exists only with FF 3.0.7 when I access the application with a domain name (www.foaf-o-matic.org), but if I load the application directly from the application invoking the exact path (http://okkam.dit.unitn.it:8081/foaf-O-matic-2/) everything works fine.

        With IE7 if I open first the application in a tab with this address http://okkam.dit.unitn.it:8081/foaf-O-matic-2/ , then I can access it also through www.foaf-o-matic.org. If I access only with www.foaf-o-matic.org nothing works.

        Hope this can help in finding the problem.

        Show
        Stefano Bortoli added a comment - In my case the problem exists also with icefaces 1.7.2SP1. The loading problem exists only with FF 3.0.7 when I access the application with a domain name (www.foaf-o-matic.org), but if I load the application directly from the application invoking the exact path ( http://okkam.dit.unitn.it:8081/foaf-O-matic-2/ ) everything works fine. With IE7 if I open first the application in a tab with this address http://okkam.dit.unitn.it:8081/foaf-O-matic-2/ , then I can access it also through www.foaf-o-matic.org. If I access only with www.foaf-o-matic.org nothing works. Hope this can help in finding the problem.
        Hide
        Mircea Toma added a comment -

        I discovered that the issue is caused by a limitation of the
        cookie based session tracking. When multiple tabs/windows are opened
        simultaneously each of them will receive a new JSESSIONID cookie because
        none of the GET requests received yet their corresponding response
        before the other ones go out, so no cookie is set in the browser that
        the subsequent requests could use. The last request that receives its
        response will overwrite the JSESSIONID cookie, thus only the last
        tab/window will have the right correspondence between JSESSIONID and
        ice.session. That is why only one tab/window will not receive the
        <session-expired/> message.
        So, this is really a limitation of the cookie based session tracking
        process.

        Show
        Mircea Toma added a comment - I discovered that the issue is caused by a limitation of the cookie based session tracking. When multiple tabs/windows are opened simultaneously each of them will receive a new JSESSIONID cookie because none of the GET requests received yet their corresponding response before the other ones go out, so no cookie is set in the browser that the subsequent requests could use. The last request that receives its response will overwrite the JSESSIONID cookie, thus only the last tab/window will have the right correspondence between JSESSIONID and ice.session. That is why only one tab/window will not receive the <session-expired/> message. So, this is really a limitation of the cookie based session tracking process.
        Hide
        Mircea Toma added a comment -

        Take into account that multiple ice.session ids can be present (especially with push-server) when verifying the request.

        Show
        Mircea Toma added a comment - Take into account that multiple ice.session ids can be present (especially with push-server) when verifying the request.
        Hide
        Mircea Toma added a comment -

        Make sure that bridge is shutdown even if exceptions occur during the shutdown process.

        Show
        Mircea Toma added a comment - Make sure that bridge is shutdown even if exceptions occur during the shutdown process.
        Hide
        Ken Fyten added a comment -

        Forum reports indicate the false "Session Expired" error is still happening on redirect navigation in some cases.

        Show
        Ken Fyten added a comment - Forum reports indicate the false "Session Expired" error is still happening on redirect navigation in some cases.
        Hide
        Ken Fyten added a comment -

        User comment from Isuru Perera on forum thread:

        I tested with revision 18684 and I still have the issue.

        Revision 18684 contains the changes for ICE-4275

        I'm not sure why this happens and I cannot reproduce the issue from my test case.

        I used Firefox 3.0.8 for testing.

        Following coding is from com.icesoft.faces.webapp.http.core.RequestVerifier.service(Request)

        Code:
        if (request.containsParameter("ice.session")) {
        if (Arrays.asList(request.getParameterAsStrings("ice.session")).contains(sessionID))

        { server.service(request); }

        else

        { log.debug("Missmatched 'ice.session' value. Session has expired."); request.respondWith(SessionExpiredResponse.Handler); }

        } else

        { log.info("Request missing 'ice.session' required parameter. Dropping connection..."); request.respondWith(EmptyResponse.Handler); }

        The problem is that sometimes "ice.session" parameter is empty (i.e. empty string).

        Therefore, following block is executed.

        Code:
        log.debug("Missmatched 'ice.session' value. Session has expired.");
        request.respondWith(SessionExpiredResponse.Handler);

        Earlier I was working with revision 18507 and there was no issue.
        (I used revision 18507 as it fixed the file upload issue with Firefox 3.0.7)

        Show
        Ken Fyten added a comment - User comment from Isuru Perera on forum thread: I tested with revision 18684 and I still have the issue. Revision 18684 contains the changes for ICE-4275 I'm not sure why this happens and I cannot reproduce the issue from my test case. I used Firefox 3.0.8 for testing. Following coding is from com.icesoft.faces.webapp.http.core.RequestVerifier.service(Request) Code: if (request.containsParameter("ice.session")) { if (Arrays.asList(request.getParameterAsStrings("ice.session")).contains(sessionID)) { server.service(request); } else { log.debug("Missmatched 'ice.session' value. Session has expired."); request.respondWith(SessionExpiredResponse.Handler); } } else { log.info("Request missing 'ice.session' required parameter. Dropping connection..."); request.respondWith(EmptyResponse.Handler); } The problem is that sometimes "ice.session" parameter is empty (i.e. empty string). Therefore, following block is executed. Code: log.debug("Missmatched 'ice.session' value. Session has expired."); request.respondWith(SessionExpiredResponse.Handler); Earlier I was working with revision 18507 and there was no issue. (I used revision 18507 as it fixed the file upload issue with Firefox 3.0.7)
        Hide
        Mircea Toma added a comment - - edited

        I discovered that there could be a very short timeframe in between window.onbeforeunload and window.onunload when the ice.sessions cookie could be empty. In case there is only one window opened to an application, the ice.sessions cookie will contain only one session#counter tuple. This tuple is erased when the window is closed because the counter has value 1. This is the strategy used to avoid accumulating unused/expired sessions into the cookie.
        The tuple is erased on window.onbeforeunload because its existence is tightly coupled to view disposal. If the blocking connection is unblocked (by a pong, or a ticking clock update) after window.onbeforeunload but before window.onunload when the bridge is completely shutdown the blocking connection will send a request with an empty ice.session parameter which is interpreted by the framework as a mismatched ice.session ID.

        So, the solution I chose was to drop the connection instead of sending a session expired command back to the bridge. Conceptually the framework just intrprets the request as invalid instead of ice.session – servlet session id mismatch.

        Show
        Mircea Toma added a comment - - edited I discovered that there could be a very short timeframe in between window.onbeforeunload and window.onunload when the ice.sessions cookie could be empty. In case there is only one window opened to an application, the ice.sessions cookie will contain only one session#counter tuple. This tuple is erased when the window is closed because the counter has value 1. This is the strategy used to avoid accumulating unused/expired sessions into the cookie. The tuple is erased on window.onbeforeunload because its existence is tightly coupled to view disposal. If the blocking connection is unblocked (by a pong, or a ticking clock update) after window.onbeforeunload but before window.onunload when the bridge is completely shutdown the blocking connection will send a request with an empty ice.session parameter which is interpreted by the framework as a mismatched ice.session ID. So, the solution I chose was to drop the connection instead of sending a session expired command back to the bridge. Conceptually the framework just intrprets the request as invalid instead of ice.session – servlet session id mismatch.
        Hide
        Krashan Brahmanjara added a comment -

        I upgrade latest Icefaces from trunk and notice that some changes between rev18808/28.04.2009 and 18861/11.05.2009 was done.

        On current version I see in logs many messages like :
        "2009-05-11 14:20:13 com.icesoft.faces.webapp.http.core.RequestVerifier service
        INFO: Request missing 'ice.session' required parameter. Dropping connection..."

        It happens on

        • Tomcat server start
        • until debugging Tomcat apps from Eclipse

        I tested only Icefaces upgrade.

        Show
        Krashan Brahmanjara added a comment - I upgrade latest Icefaces from trunk and notice that some changes between rev18808/28.04.2009 and 18861/11.05.2009 was done. On current version I see in logs many messages like : "2009-05-11 14:20:13 com.icesoft.faces.webapp.http.core.RequestVerifier service INFO: Request missing 'ice.session' required parameter. Dropping connection..." It happens on Tomcat server start until debugging Tomcat apps from Eclipse I tested only Icefaces upgrade.

          People

          • Assignee:
            Unassigned
            Reporter:
            Ken Fyten
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: