ICEfaces
  1. ICEfaces
  2. ICE-1921

Need to clear browser cookie cache when redeploying applications

          Details

          • Type: Improvement Improvement
          • Status: Closed
          • Priority: Major Major
          • Resolution: Cannot Reproduce
          • Affects Version/s: 1.6
          • Fix Version/s: 1.7Beta1, 1.7
          • Component/s: Framework
          • Labels:
            None
          • Environment:
            win xp
          • Workaround Exists:
            Yes
          • Workaround Description:
            Hide
            It turns out that if you wait long enough, all viewports will eventually fail with "Connection Lost" messages. If this happens, the cookies are cleaned up okay and you can continue to use the application after you redeploy it without having to clear cookies or restart the browser.

            NOTE: In order to avoid this issue, you must allow each viewport in the browser to fail with either a "Session Lost" or "Connection Lost" message before you attempt to reload the application in the browser, or the cookies from the previous session will not be cleared.

            A work-around might be to set the async ping timing (in the web.xml) to something more aggressive (5 secs?) during development so that the connection lost failure occurs much sooner after the web-app is undeployed:

            The following code example defines the time in milliseconds between heartbeat messages. The default value is 20000 (20 seconds), setting it to 5 seconds will make the wait for the failure message more tolerable for some.

            <context-param>
            <param-name>com.icesoft.faces.heartbeatInterval</param-name>
            <param-value>5000</param-value>
            </context-param>
             
            Show
            It turns out that if you wait long enough, all viewports will eventually fail with "Connection Lost" messages. If this happens, the cookies are cleaned up okay and you can continue to use the application after you redeploy it without having to clear cookies or restart the browser. NOTE: In order to avoid this issue, you must allow each viewport in the browser to fail with either a "Session Lost" or "Connection Lost" message before you attempt to reload the application in the browser, or the cookies from the previous session will not be cleared. A work-around might be to set the async ping timing (in the web.xml) to something more aggressive (5 secs?) during development so that the connection lost failure occurs much sooner after the web-app is undeployed: The following code example defines the time in milliseconds between heartbeat messages. The default value is 20000 (20 seconds), setting it to 5 seconds will make the wait for the failure message more tolerable for some. <context-param> <param-name>com.icesoft.faces.heartbeatInterval</param-name> <param-value>5000</param-value> </context-param>  

            Description

            redeploying ICEfaces pps require either restarting the app server or clearing browser cookies. Or else a SessionExpiredException may occur:

             20.07.2007 10:47:46 *ERROR* ([Persistent Faces Servlet]) : Servlet.service() for servlet Persistent Faces Servlet threw exception
            javax.servlet.ServletException: Session expired
            at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.service(SessionDispatcher.java:38)
            at com.icesoft.faces.webapp.http.servlet.PathDispatcher$Matcher.serviceOnMatch(PathDispatcher.java:52)
            at com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:29)
            at com.icesoft.faces.webapp.http.servlet.MainServlet.service(MainServlet.java:65)
            at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
            at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
            at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
            at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
            at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
            at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
            at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
            ...

              Activity

              Ascending order - Click to sort in descending order
              4 older comments
              Hide
              Permalink
              Ken Fyten added a comment -

              Using ICEfaces 1.7 DR#3, auctionMonitor sample.

              1. Deploy auctionMonitor.war to webapps dir in Tomcat 6.0
              2. Launch http://localhost:8080/auctionMonitor/ in your browser into two separate tabs or windows
              3. Build an updated version of auctionMonitor.war and copy it overtop of the existing one in webapps
              4. See that the Connection lost message appears on one of the tabs
              5. Click the "Reload" button (on both tabs)
              6. Page reloads, but no async (clocks don't tick).
              7. Clear cookies and reload or shutdown browser and re-launch and it works correctly.

              Show
              Ken Fyten added a comment - Using ICEfaces 1.7 DR#3, auctionMonitor sample. 1. Deploy auctionMonitor.war to webapps dir in Tomcat 6.0 2. Launch http://localhost:8080/auctionMonitor/ in your browser into two separate tabs or windows 3. Build an updated version of auctionMonitor.war and copy it overtop of the existing one in webapps 4. See that the Connection lost message appears on one of the tabs 5. Click the "Reload" button (on both tabs) 6. Page reloads, but no async (clocks don't tick). 7. Clear cookies and reload or shutdown browser and re-launch and it works correctly.
              Hide
              Permalink
              Ken Fyten added a comment -

              Refinement of above instructions:

              It turns out that if you wait long enough, all viewports will eventually fail with "Connection Lost" messages. If this happens, the cookies are cleaned up okay and you can continue to use the application after you redeploy it without having to clear cookies or restart the browser.

              NOTE: In order to avoid this issue, you must allow each viewport in the browser to fail with either a "Session Lost" or "Connection Lost" message before you attempt to reload the application in the browser, or the cookies from the previous session will not be cleared.

              A work-around might be to set the async ping timing to something more aggressive (5 secs?) during development so that the connection lost failure occurs much sooner after the web-app is undeployed:

              The following code example defines the time in milliseconds between heartbeat messages. The default value is 20000 (20 seconds).

              <context-param>
              <param-name>com.icesoft.faces.heartbeatInterval</param-name>
              <param-value>5000</param-value>
              </context-param>

              Show
              Ken Fyten added a comment - Refinement of above instructions: It turns out that if you wait long enough, all viewports will eventually fail with "Connection Lost" messages. If this happens, the cookies are cleaned up okay and you can continue to use the application after you redeploy it without having to clear cookies or restart the browser. NOTE: In order to avoid this issue, you must allow each viewport in the browser to fail with either a "Session Lost" or "Connection Lost" message before you attempt to reload the application in the browser, or the cookies from the previous session will not be cleared. A work-around might be to set the async ping timing to something more aggressive (5 secs?) during development so that the connection lost failure occurs much sooner after the web-app is undeployed: The following code example defines the time in milliseconds between heartbeat messages. The default value is 20000 (20 seconds). <context-param> <param-name>com.icesoft.faces.heartbeatInterval</param-name> <param-value>5000</param-value> </context-param>
              Hide
              Permalink
              Ken Fyten added a comment -

              Further testing with both 1.6.2 and 1.7 trunk (pre-Beta1) shows the following behavior:

              1. Deploy auctionMonitor.war to webapps dir in Tomcat 6.0
              2. Launch http://localhost:8080/auctionMonitor/ in your browser into two separate tabs or windows
              3. Build an updated version of auctionMonitor.war and copy it overtop of the existing one in webapps
              4. See the "Session Expired" message appear on both tabs.
              5. Click the "Reload" button (on both tabs).
              6. Page reloads, everything working properly.

              It seems that so long as the bridge is notified of a failure (either session expired for connection lost) the cookies are cleaned up and everything proceeds as expected. However, if the browser tab is reloaded prior to the bridge displaying an error message the cookies from the previous session will be used an cause the issue that requires the browser to be closed or the cookies to be removed to resolve.

              Show
              Ken Fyten added a comment - Further testing with both 1.6.2 and 1.7 trunk (pre-Beta1) shows the following behavior: 1. Deploy auctionMonitor.war to webapps dir in Tomcat 6.0 2. Launch http://localhost:8080/auctionMonitor/ in your browser into two separate tabs or windows 3. Build an updated version of auctionMonitor.war and copy it overtop of the existing one in webapps 4. See the "Session Expired" message appear on both tabs. 5. Click the "Reload" button (on both tabs). 6. Page reloads, everything working properly. It seems that so long as the bridge is notified of a failure (either session expired for connection lost) the cookies are cleaned up and everything proceeds as expected. However, if the browser tab is reloaded prior to the bridge displaying an error message the cookies from the previous session will be used an cause the issue that requires the browser to be closed or the cookies to be removed to resolve.
              Hide
              Permalink
              Ken Fyten added a comment -

              In order to remove the potential for this issue to arise we should make the bridge cookie mgmt. more robust, perhaps adding logic to associate cookies to a particular session id, etc.

              Show
              Ken Fyten added a comment - In order to remove the potential for this issue to arise we should make the bridge cookie mgmt. more robust, perhaps adding logic to associate cookies to a particular session id, etc.
              Hide
              Permalink
              Mircea Toma added a comment -

              I tried reloading the page before and after receiving the 'Session Expired' message, but I could not reproduce this issue. I looked at the code and the cookies are cleared on page load as well, which confirms what I am seeing.

              Show
              Mircea Toma added a comment - I tried reloading the page before and after receiving the 'Session Expired' message, but I could not reproduce this issue. I looked at the code and the cookies are cleared on page load as well, which confirms what I am seeing.

                People

                • Assignee:
                  Unassigned
                  Reporter:
                  Philip Breau
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: