ICEfaces
  1. ICEfaces
  2. ICE-10758

Deadlock in SessionDispatcher

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: EE-1.8.2.GA_P08
          • Fix Version/s: EE-1.8.2.GA_P09
          • Component/s: Framework
          • Labels:
            None
          • Environment:
            Tomcat, OC4J
          • Assignee Priority:
            P1
          • Support Case References:
             Support case #13482 and #13486

            Description

            On session expiry coupled with a page redirect causes the framework to lockup with the following thread dump:

            Found one Java-level deadlock:
            =============================
            "Session Monitor":
              waiting to lock monitor 0x003e4b9c (object 0x0a2a03a0, a java.util.HashMap),
              which is held by "HTTPThreadGroup-6"
            "HTTPThreadGroup-6":
              waiting to lock monitor 0x003e4bbc (object 0x0acf4880, a com.evermind.server.http.EvermindHttpSession),
              which is held by "Session Monitor"

            Java stack information for the threads listed above:
            ===================================================
            "Session Monitor":
            at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.notifySessionShutdown(SessionDispatcher.java:272)
            - waiting to lock <0x0a2a03a0> (a java.util.HashMap)
            at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.access$400(SessionDispatcher.java:73)
            at com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Listener.sessionDestroyed(SessionDispatcher.java:361)
            at com.icesoft.faces.util.event.servlet.ContextEventRepeater.sessionDestroyed(ContextEventRepeater.java:319)
            at com.evermind.server.http.HttpApplication.invalidateSession(HttpApplication.java:996)
            at com.evermind.server.http.HttpApplication.invalidateSession(HttpApplication.java:978)
            at com.evermind.server.http.EvermindHttpSession.invalidate(EvermindHttpSession.java:411)
            - locked <0x0acf4880> (a com.evermind.server.http.EvermindHttpSession)
            at com.evermind.server.http.EvermindHttpSession.invalidate(EvermindHttpSession.java:378)
            - locked <0x0acf4880> (a com.evermind.server.http.EvermindHttpSession)
            at com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Monitor.shutdown(SessionDispatcher.java:445)
            at com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Monitor.shutdownIfExpired(SessionDispatcher.java:457)
            at com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Listener$1.run(SessionDispatcher.java:325)
            "HTTPThreadGroup-6":
            at com.evermind.server.http.EvermindHttpSession.setAttribute(EvermindHttpSession.java:171)
            - waiting to lock <0x0acf4880> (a com.evermind.server.http.EvermindHttpSession)
            at com.evermind.server.http.EvermindHttpSession.setAttribute(EvermindHttpSession.java:137)
            at com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Monitor.<init>(SessionDispatcher.java:388)
            at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.checkSession(SessionDispatcher.java:136)
            - locked <0x0a2a03a0> (a java.util.HashMap)
            at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.service(SessionDispatcher.java:96)
            at com.icesoft.faces.webapp.http.servlet.BlockExpiredSessionRequests.service(BlockExpiredSessionRequests.java:53)
            at com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:55)
            at com.icesoft.faces.webapp.http.servlet.MainServlet.service(MainServlet.java:204)
            at ***.***Servlet.service(***Servlet.java:149)
            at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
            at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:734)
            at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:391)
            at com.evermind.server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:908)
            at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:458)
            at com.evermind.server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:226)
            at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:127)
            at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:116)
            at oracle.oc4j.network.ServerSocketReadHandler$SafeRunnable.run(ServerSocketReadHandler.java:260)
            at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
            at java.lang.Thread.run(Thread.java:595)

            Found 1 deadlock.
             

              Activity

              Ascending order - Click to sort in descending order
              5 older comments
              Hide
              Permalink
              Arran Mccullough added a comment -

              I'm seeing inconsistent results now. I'm able to see the popup now with my test case (running on Tomcat 8.0.9.0). Yesterday I wasn't able to see this popup, now I can. Even after cleaning out my browser and Tomcat caches I wasn't getting the timeout popup. I can consistently see it now though...

              Show
              Arran Mccullough added a comment - I'm seeing inconsistent results now. I'm able to see the popup now with my test case (running on Tomcat 8.0.9.0). Yesterday I wasn't able to see this popup, now I can. Even after cleaning out my browser and Tomcat caches I wasn't getting the timeout popup. I can consistently see it now though...
              Hide
              Permalink
              Liana Munroe added a comment -

              Used strictSessionTimeout=true in the web.xml
              3 tests with FF - popup occurred at 1:30, 49 secs and 1:26
              3 tests with IE - similar time frames to FF test
              1 test with Chrome with cleared cache, popup occurred at 1:30,
              2 tests with Chrome - no popup. Stopped tests after 2 mins each. (cache was not cleared for these tests)

              Show
              Liana Munroe added a comment - Used strictSessionTimeout=true in the web.xml 3 tests with FF - popup occurred at 1:30, 49 secs and 1:26 3 tests with IE - similar time frames to FF test 1 test with Chrome with cleared cache, popup occurred at 1:30, 2 tests with Chrome - no popup. Stopped tests after 2 mins each. (cache was not cleared for these tests)
              Hide
              Permalink
              Ken Fyten added a comment -

              Seems like it only works the 1st time after a cleared cache and server restart reliably, or something like that. Try multiple browsers with multiple test attempts without clearing the cache to reproduce.

              Show
              Ken Fyten added a comment - Seems like it only works the 1st time after a cleared cache and server restart reliably, or something like that. Try multiple browsers with multiple test attempts without clearing the cache to reproduce.
              Hide
              Permalink
              Mircea Toma added a comment -

              Indeed the previous commit introduced a regression where the session's last access timestamp is updated on any kind of request.

              The fix avoids touching the session's last access time for any request (push requests in particular) and initialises the timestamp only when the session monitor is created.

              Show
              Mircea Toma added a comment - Indeed the previous commit introduced a regression where the session's last access timestamp is updated on any kind of request. The fix avoids touching the session's last access time for any request (push requests in particular) and initialises the timestamp only when the session monitor is created.
              Hide
              Permalink
              Liana Munroe added a comment -

              Tested using ICEfaces r45867, Tomcat 7, IE 11, 10, 9, FF 34, Chrome 43 with the following results:
              3 tests with FF - popup occurred at 1:02, 49 secs and 46 secs
              3 tests with Chrome - popup occurred at 49 secs, 51 secs and 44 secs
              3 tests with IE 11- popup occurred at 52 secs, 44 secs and 48 secs
              2 tests with IE 10 - popup ocurred at 47 secs, 46 secs.
              2 tests with IE 9 - popup ocurred at 52 secs, 51 secs.
              Session expired with or without using the "test" button on the page before starting timer.
              Did not have to clear browser cache or restart server between tests. Was able to test in multiple browsers without restarting server or closing other browser windows. Did not use strictSessionTimeout=true in the web.xml

              Show
              Liana Munroe added a comment - Tested using ICEfaces r45867, Tomcat 7, IE 11, 10, 9, FF 34, Chrome 43 with the following results: 3 tests with FF - popup occurred at 1:02, 49 secs and 46 secs 3 tests with Chrome - popup occurred at 49 secs, 51 secs and 44 secs 3 tests with IE 11- popup occurred at 52 secs, 44 secs and 48 secs 2 tests with IE 10 - popup ocurred at 47 secs, 46 secs. 2 tests with IE 9 - popup ocurred at 52 secs, 51 secs. Session expired with or without using the "test" button on the page before starting timer. Did not have to clear browser cache or restart server between tests. Was able to test in multiple browsers without restarting server or closing other browser windows. Did not use strictSessionTimeout=true in the web.xml

                People

                • Assignee:
                  Mircea Toma
                  Reporter:
                  Mircea Toma
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: