Hi Carlin
Does the included jsp's need to pass through the filter?
<filter-mapping>
<filter-name>PageFlowJspFilter</filter-name>
<url-pattern>*.jsp</url-pattern>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
<dispatcher>INCLUDE</dispatcher>
</filter-mapping>
<filter-mapping>
<filter-name>PageFlowJspFilter</filter-name>
<url-pattern>*.jspx</url-pattern>
<dispatcher>FORWARD</dispatcher>
<dispatcher>REQUEST</dispatcher>
<dispatcher>INCLUDE</dispatcher>
</filter-mapping>
Do we need to have the INCLUDE in the above filters in web.xml
If we use the jsp tag files instead of jsp:includes, it should not have this
problem right ??????
But we had lot of jsp:includes in our app. When do you think the bug will be
fixed?? Is it considered a high priority bug?
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
