Sorry, missed your earlier post and question...
If we run into these issues more, can we safely remove the entry in
web.xml for > HttpSessionMutexListener?
Do we see any problems with that?
I don't think removing the entry for the HttpSessionMutexListener will help because the code path in your scenario will still have concurrent threads trying to get locks in a different order. If the HttpSessionMutexListener is not registered the DeferredSessionStorageHandler will try to lock on the session object itself rather than the mutex object in the session. Sorry. Carlin On 7/21/06, Carlin Rogers <[EMAIL PROTECTED]> wrote:
Hi Srinivas, Seems like this is a bug. I've opened an issue in JIRA, http://issues.apache.org/jira/browse/BEEHIVE-1135 . From your stack trace, Thread '2' has processed a request for an action in the FinanceCompanyController. In your environment, using a portal, the requests going to the PageFlowUtils.strutsLookup() which calls DeferredSessionStorageHandler.applyChanges() and first gets a lock mutex object for the user session. The method then tries to get a lock for the current page flow object (FinanceCompanyController). However the lock order is reversed for Thread '0'. This thread is in the PageFlowPageFilter and has got a lock on the current page flow object (FinanceCompanyController). The processing of addeditfinancecompany.jspdoes an include. The include() for the other JSP goes through the PageFlowPageFilter again and after processing the included JSP it tries to save some page flow session-scoped state. That's the call to DeferredSessionStorageHandler.applyChanges () which waits for the mutex object of the user session. Any chance you can avoid the JSP include as a temporary workaround until the bug is fixed? Or is it likely you will get these concurrent requests to this page flow controller from the user? Hope the explanation helps. Kind regards, Carlin On 7/20/06, Carlin Rogers <[EMAIL PROTECTED] > wrote: > > Hi Srinivas, > > Thanks for the reply and for sending along the stack trace. I can take a > look at this and the locking code tomorrow to see if there's an ordering > problem causing the deadlock. > > Kind regards, > Carlin > > > On 7/20/06, Srinivas Surapaneni < [EMAIL PROTECTED]> wrote: > > > > Hi Carlin, > > > > The included jsp is part of the same pageflow > > > > I saw this only on a WLP 9.2 running on Redhat Linux 4.0 > > > > I did not see this on XP development machines. > > > > Other threads are also waiting on > > DeferredSessionStorageHandler.applyChanges > > > > Thank You > > Srinivas Surapaneni > > > > > > > > > > > > -----Original Message----- > > From: Carlin Rogers [mailto: [EMAIL PROTECTED] ] > > Sent: Thursday, July 20, 2006 4:07 PM > > To: Beehive Users > > Subject: Re: Deadlocks in HttpSessionMutexListener > > > > Hi Srinivas, > > > > I've not seen this deadlock before. Can you provide some detail about > > what > > the cocurrent threads are doing. From the stack trace, there is a JSP > > which > > is doing an include of another JSP, correct, and waiting for the lock? > > Are > > the JSP associated with the saem page flows, different page flows, or > > is one > > not associated with a page flow. Do you have information about the > > other > > thread with the lock? > > > > Thanks, > > Carlin > > > > On 7/20/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > > > > > We are seeing deadlocks around HttpSessionMutexListener > > > > > > Has anyone sees this behavior? > > > > > > [deadlocked thread] [ACTIVE] ExecuteThread: '0' for queue: ' > > > weblogic.kernel.Default (self-tuning)': > > > > > > > > > > ---------------------------------------------------------------------------- > > ---------------------- > > > Thread '[ACTIVE] ExecuteThread: '0' for queue: > > 'weblogic.kernel.Default(self-tuning)'' is waiting to acquire lock ' > > > > > [EMAIL PROTECTED] > > ' > > > that is held by thread '[ACTIVE] ExecuteThread: '2' for queue: ' > > > weblogic.kernel.Default (self-tuning)'' > > > Stack trace: > > > ------------ > > > jrockit.vm.Threads.shortNap(Native Method) > > > jrockit.vm.Locks.waitForThinRelease(Unknown Source) > > > jrockit.vm.Locks.monitorEnterSecondStage (Unknown Source) > > > jrockit.vm.Locks.monitorEnter(Unknown Source) > > > > > > > > > > org.apache.beehive.netui.pageflow.internal.DeferredSessionStorageHandler.app > > lyChanges > > > (DeferredSessionStorageHandler.java :203) > > > org.apache.beehive.netui.pageflow.PageFlowPageFilter.doFilter( > > > PageFlowPageFilter.java:281) > > > weblogic.servlet.internal.FilterChainImpl.doFilter( > > FilterChainImpl.java > > > :42) > > > weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet ( > > > RequestDispatcherImpl.java:497) > > > weblogic.servlet.internal.RequestDispatcherImpl.include( > > > RequestDispatcherImpl.java:427) > > > weblogic.servlet.jsp.PageContextImpl.include(PageContextImpl.java:152) > > > > > > > > > > jsp_servlet._pageflows._partyconfiguration._financecompany.__addeditfinancec > > ompany._jspService(__addeditfinancecompany.java:292) > > > weblogic.servlet.jsp.JspBase.service(JspBase.java:34) > > > > > weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run( > > > StubSecurityHelper.java:225) > > > weblogic.servlet.internal.StubSecurityHelper.invokeServlet( > > > StubSecurityHelper.java:127) > > > weblogic.servlet.internal.ServletStubImpl.execute( > > ServletStubImpl.java > > > :283) > > > weblogic.servlet.internal.ServletStubImpl.onAddToMapException( > > > ServletStubImpl.java:391) > > > weblogic.servlet.internal.ServletStubImpl.execute ( > > ServletStubImpl.java > > > :309) > > > weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) > > > weblogic.servlet.internal.FilterChainImpl.doFilter( > > FilterChainImpl.java > > > :42) > > > org.apache.beehive.netui.pageflow.PageFlowPageFilter.runPage ( > > > PageFlowPageFilter.java:347) > > > org.apache.beehive.netui.pageflow.PageFlowPageFilter.doFilter( > > > PageFlowPageFilter.java:251) > > > weblogic.servlet.internal.FilterChainImpl.doFilter( > > FilterChainImpl.java > > > :42) > > > weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet( > > > RequestDispatcherImpl.java:497) > > > weblogic.servlet.internal.RequestDispatcherImpl.include( > > > RequestDispatcherImpl.java :427) > > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.1.394 / Virus Database: 268.10.3/394 - Release Date: > > 7/20/2006 > > > > > > -- > > No virus found in this outgoing message. > > Checked by AVG Free Edition. > > Version: 7.1.394 / Virus Database: 268.10.3/394 - Release Date: > > 7/20/2006 > > > > > > >
