Uploaded image for project: 'Jetspeed 2'
  1. Jetspeed 2
  2. JS2-795

Deadlock while release session on Websphere Release 6.0.2.19

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.1, 2.1.2, 2.1.3, 2.2.0
    • Fix Version/s: 2.1.3, 2.2.0
    • Component/s: Container
    • Labels:
      None

      Description

      We experienced deadlock situation while releasing session on Websphere Release 6.0.2.19 using Jetspeed-2.1. The Problem is also still existent in trunk and occurs in PortalSessionsManagerImpl.

      The attached screenshot documents the deadlock situation.

      Thread Name : Non-deferrable Alarm : 3
      State : Waiting on condition
      Owns Monitor Lock on com.ibm.ws.webcontainer.httpsession.MemorySessionData@53FAA6C8/53FAA6D0
      Java Stack
      at org.apache.jetspeed.container.session.PortletApplicationSessionMonitorImpl.valueUnbound(PortletApplicationSessionMonitorImpl.java(Compiled Code))
      at com.ibm.ws.webcontainer.httpsession.SessionData.processListeners(SessionData.java(Compiled Code))
      at com.ibm.ws.webcontainer.httpsession.SessionData.checkSwappableListeners(SessionData.java(Compiled Code))
      at com.ibm.ws.webcontainer.httpsession.SessionData.sessionUnbound(SessionData.java(Compiled Code))
      at com.ibm.ws.webcontainer.httpsession.SessionContext.notifySessionInvalidated(SessionContext.java(Compiled Code))
      at com.ibm.ws.webcontainer.httpsession.SessionData.invalidate(SessionData.java(Compiled Code))
      ...
      Thread Name : Non-deferrable Alarm : 1
      State : Waiting on condition
      Waiting for Monitor Lock on com.ibm.ws.webcontainer.httpsession.MemorySessionData@53FAA6C8/53FAA6D0
      Owns Monitor Lock on org.apache.jetspeed.container.session.PortalSessionsManagerImpl@31582908/31582910
      Java Stack
      at com.ibm.ws.webcontainer.httpsession.SessionData.invalidate(SessionData.java(Compiled Code))
      at org.apache.jetspeed.container.session.PortletApplicationSessionMonitorImpl.invalidateSession(PortletApplicationSessionMonitorImpl.java(Compiled Code))
      at org.apache.jetspeed.container.session.PortalSessionsManagerImpl.portalSessionDestroyed(PortalSessionsManagerImpl.java(Compiled Code))
      at org.apache.jetspeed.container.session.PortalSessionMonitorImpl.valueUnbound(PortalSessionMonitorImpl.java(Compiled Code))
      at com.ibm.ws.webcontainer.httpsession.SessionData.processListeners(SessionData.java(Compiled Code))
      at com.ibm.ws.webcontainer.httpsession.SessionData.checkSwappableListeners(SessionData.java(Compiled Code))
      at com.ibm.ws.webcontainer.httpsession.SessionData.sessionUnbound(SessionData.java(Compiled Code))
      at com.ibm.ws.webcontainer.httpsession.SessionContext.notifySessionInvalidated(SessionContext.java(Compiled Code))
      at com.ibm.ws.webcontainer.httpsession.SessionData.invalidate(SessionData.java(Compiled Code))
      ...
      ---------------------------

      Other threads pile up because of this situation.
      ---------------------------
      Thread Name : WebContainer : 9
      State : Waiting on monitor
      Waiting for Monitor Lock on org.apache.jetspeed.container.session.PortalSessionsManagerImpl@31582908/31582910
      Java Stack
      at org.apache.jetspeed.container.session.PortalSessionsManagerImpl.checkMonitorSession(PortalSessionsManagerImpl.java(Compiled Code))
      at org.apache.jetspeed.container.JetspeedContainerServlet.doGet(JetspeedContainerServlet.java(Compiled Code))
      at org.apache.jetspeed.container.JetspeedContainerServlet.doPost(JetspeedContainerServlet.java(Compiled Code))
      at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code))
      at javax.servlet.http.HttpServlet.service(HttpServlet.java(Compiled Code))

      What happens:

      1.) thread1: Websphere releases the session, LOCKS the SessionData and PortletApplicationSessionMonitorImpl.valueUnbound is called

      2.) thread2: <synchronized> PortalSessionsManagerImpl.portalSessionDestroyed is called by PortalSessionMonitorImpl.valueUnbound (called by the Container as well) and waits for lock on SessionData

      3.) thread1: PortletApplicationSessionMonitorImpl.valueUnbound tries to call <synchronized> PortletApplicationSessionMonitorImpl.sessionDestroyed which is blocked by thread2

      The patch supplied removes all synchronized methods from the PortalSessionsManagerImpl. This can be done because the Maps sessionMonitors and portalSessionsRegistry are SynchronizedMaps. The iteration over the elements of the maps is done via a shallow copy of the SynchronizedMaps, so a change of the original Map does not affect the iteration process.

        Attachments

        1. PortalSessionsManagerImpl.java.diff
          7 kB
          Joachim Müller
        2. debug-information.gif
          97 kB
          Joachim Müller

          Activity

            People

            • Assignee:
              woon_san Woonsan Ko
              Reporter:
              joachim_mueller Joachim Müller
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: