beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlin Rogers (JIRA)" <...@beehive.apache.org>
Subject [jira] Resolved: (BEEHIVE-1135) NetUI deadlock condition for concurrent requests to an action and a JSP with a JSP include
Date Thu, 03 Aug 2006 16:00:14 GMT
     [ http://issues.apache.org/jira/browse/BEEHIVE-1135?page=all ]

Carlin Rogers resolved BEEHIVE-1135.
------------------------------------

    Resolution: Fixed
      Assignee: Julie Zhuo

This is fixed with svn revision 428434...
http://svn.apache.org/viewvc?rev=428434&view=rev

>From within the PageFlowPageFilter, we now place an attribute on the request that lets
us determine if the filter is already set to commit any session-scoped changes for a JSP and
a given page flow module, with the storage handler. Then if the page includes another JSP
associated to the page flow, it will not try to commit changes. This will ensure we don't
get locks out of order. We only do this if the request is not a forward from the PageFlowRequestProcessor.

> NetUI deadlock condition for concurrent requests to an action and a JSP with a JSP include
> ------------------------------------------------------------------------------------------
>
>                 Key: BEEHIVE-1135
>                 URL: http://issues.apache.org/jira/browse/BEEHIVE-1135
>             Project: Beehive
>          Issue Type: Bug
>          Components: NetUI
>    Affects Versions: v.next
>            Reporter: Carlin Rogers
>         Assigned To: Julie Zhuo
>             Fix For: v.next
>
>
> Here's a scenario that will cause a deadlock in NetUI for concurrent requests to a page
flow controller action and a JSP for that controller that includes another JSP for the same
controller. 
> The issue is a difference in the lock order introduced by the JSP include.
> The request to an action ("begin.do") may execute, forward to the JSP, then after the
forward to the JSP has been completed, the PageFlowRequestProcessor will call the DeferredSessionStorageHandler
(DSSH) method applyChanges(). It will commit any session-scoped changes that were stored in
the request. DSSH first gets a lock on a NetUI session mutex object, then get a lock on the
current page flow.
> However, the direct request to the JSP that includes another JSP will have a reversed
lock order. In general, the PageFlowPageFilter (PFPF) first gets a lock on the current page
flow the runs the page (chain.doFilter()). After the page has run the page flow lock is released.
If the request is not a page flow forwarded request, then it calls the DSSH.applyChanges()
as above. The deadlock occurs with a direct request to a JSP that includes another JSP because
the lock order will be page flow object then session mutex object.
> The PFPF has a lock on the current page flow and processes the page with the include.
The RequestDispatcher.include() goes through the PFPF again (same thread, so no wait on the
synchronized lock on the page flow) and processes the included JSP. Then the PFPF call to
DSSH.applyChanges() gets a lock on the NetUI session mutex... a different order!
> Here's an outline of an example page flow and JSP that might clarify my description above.
> page flow implemented...
> src/
>     deadlock/
>         Controller.java    ("begin.do" forwards to index.jsp)
> web/
>     deadlock/
>         index.jsp    (includes more.jsp)
>         more.jsp
> The scenario goes like this...
> - Thread A is request to /webappcontext/deadlock/begin.do
> - Thread B is a request to  /webappcontext/deadlock/index.jsp
> A: PageFlowRequestProcessor execute action
> A: call DSSH.applyChanges()
> A: get lock on session mutex
> B: PageFlowPageFilter lock on current page flow
> B: chain.doFilter() process requested JPF
> A: try to get lock on current page flow (WAIT)
> B: RequestDispatcher.include() another JPF
> B: PageFlowPageFilter lock on current page flow (no wait)
> B: chain.doFilter() process included JPF
> B: call DSSH.applyChanges()
> B: try to get lock on session mutex (WAIT)
> and now in deadlock!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message