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

        Hide
        Mircea Toma added a comment -

        Modified SessionDispatcher.checkSession method to associate the monitor to the session outside the synchronized block thus avoiding potential deadlocks when HttpSession implementation is synchronized.

        Show
        Mircea Toma added a comment - Modified SessionDispatcher.checkSession method to associate the monitor to the session outside the synchronized block thus avoiding potential deadlocks when HttpSession implementation is synchronized.
        Hide
        Arran Mccullough added a comment -

        Found an issue with these changes. The session no longer expires on session timeout/inactivity.

        Show
        Arran Mccullough added a comment - Found an issue with these changes. The session no longer expires on session timeout/inactivity.
        Hide
        Mircea Toma added a comment -

        I don't see any problems with the session expiration. Arran, please make sure you restart the app server after you modify the expiry timeout, Tomcat will pick the new value on restart only.

        Show
        Mircea Toma added a comment - I don't see any problems with the session expiration. Arran, please make sure you restart the app server after you modify the expiry timeout, Tomcat will pick the new value on restart only.
        Hide
        Arran Mccullough added a comment -

        When I do my testing I shut the server down and start it again between tests. This should apply the session timeout value correct? If I change the jars from the patched build to the standard P08 release, I can see the timeout correctly. I have it set to 1 minute in my sample. The customer is setting the timeout as follows:

        We are setting the session timeout on our ServletFilter by calling session.setMaxInactiveInterval()

        When they test between the patched P08 and P04 releases they have in use, they get the timeout in the P04 jars but not with the P08.

        Show
        Arran Mccullough added a comment - When I do my testing I shut the server down and start it again between tests. This should apply the session timeout value correct? If I change the jars from the patched build to the standard P08 release, I can see the timeout correctly. I have it set to 1 minute in my sample. The customer is setting the timeout as follows: We are setting the session timeout on our ServletFilter by calling session.setMaxInactiveInterval() When they test between the patched P08 and P04 releases they have in use, they get the timeout in the P04 jars but not with the P08.
        Hide
        Arran Mccullough added a comment -

        Attached test case.

        After 1 min of inactivity the User Session Expired popup should be shown. Even after clicking the commandButton 'Test' the session is not expired.

        Show
        Arran Mccullough added a comment - Attached test case. After 1 min of inactivity the User Session Expired popup should be shown. Even after clicking the commandButton 'Test' the session is not expired.
        Hide
        Mircea Toma added a comment -

        The test ran fine for me. I could see the session expiry popup after 1 minute. What server do you use?

        Show
        Mircea Toma added a comment - The test ran fine for me. I could see the session expiry popup after 1 minute. What server do you use?
        Hide
        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
        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
        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
        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
        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: