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

        Ken Fyten created issue -
        Ken Fyten made changes -
        Field Original Value New Value
        Salesforce Case []
        Fix Version/s 1.8 [ 10161 ]
        Assignee Priority P1
        Assignee Mircea Toma [ mircea.toma ]
        Priority Major [ 3 ] Critical [ 2 ]
        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.
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #18680 Fri Mar 27 16:44:53 MDT 2009 mircea.toma ICE-4275 Take into account that multiple ice.session ids can be present (especially with push-server) when verifying the request.
        Files Changed
        Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/core/RequestVerifier.java
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #18682 Fri Mar 27 16:51:51 MDT 2009 mircea.toma ICE-4275 Make sure that bridge is shutdown even if exceptions occur during the shutdown process.
        Files Changed
        Commit graph MODIFY /icefaces/trunk/icefaces/bridge/src/application.js
        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.
        Ken Fyten made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee Priority P1
        Resolution Fixed [ 1 ]
        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.
        Ken Fyten made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Assignee Priority P1
        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)
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #18693 Mon Mar 30 16:43:50 MDT 2009 mircea.toma ICE-4275 Drop connection that does not contain non-empty ice.session parameter.
        Files Changed
        Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/core/RequestVerifier.java
        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.
        Mircea Toma made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Assignee Priority P1
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Assignee Mircea Toma [ mircea.toma ]
        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: