portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Müller (JIRA) <jetspeed-...@portals.apache.org>
Subject [jira] Created: (JS2-795) Deadlock while release session on Websphere Release 6.0.2.19
Date Wed, 24 Oct 2007 10:13:50 GMT
Deadlock while release session on Websphere Release 6.0.2.19
------------------------------------------------------------

                 Key: JS2-795
                 URL: https://issues.apache.org/jira/browse/JS2-795
             Project: Jetspeed 2
          Issue Type: Bug
          Components: Container
    Affects Versions: 2.1, 2.1.2, 2.1.3, 2.2
            Reporter: Joachim Müller
             Fix For: 2.1.3, 2.2


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.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message