Hi Srinivas, Yes, that's what I was asking. Are you seeing the deadlock and stack trace under a simulated load using some load testing software? I was just curious how likely it was for you to see the concurrent requests. The locks or synchronization in the NetUI code are only on objects from the user's session... a mutex object and the current page flow. Any thoughts about what conditions were when the deadlock occurred. Were you seeing the deadlock under simulated load using the load testing software? Just curious.
From your other questions on a previous email...
1) Yes, I think you need to have the INCLUDE in the filter-mapping for PageFlowJspFilter in web.xml. 2) Correct, using a jsp tag files instead of jsp:includes will not have this problem. This would be a good work around until you pick up the fix. I have submitted a change into the Apache svn repository for beehive for BEEHIVE-1135. If you are able to build the NetUI jars from svn and test, please let me know if the fix works for you. Kind regards, Carlin On 7/21/06, Srinivas Surapaneni <[EMAIL PROTECTED]> wrote:
Hi Carlin Can you clarify on your question below is it likely you will get these concurrent requests to this page flow controller from the user? It is not likely concurrent requests will come to the same pageflow controller from the same user session. This will happen only if the user do a double submit or refresh the browser without completing the first request. Is that you are asking? Thank You Srinivas Surapaneni -----Original Message----- From: Carlin Rogers [mailto:[EMAIL PROTECTED] Sent: Friday, July 21, 2006 4:13 PM To: Beehive Users Subject: Re: Deadlocks in HttpSessionMutexListener 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 > > > > > > > > > > > > -- 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
