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] Commented: (BEEHIVE-1135) NetUI deadlock condition for concurrent requests to an action and a JSP with a JSP include
Date Thu, 03 Aug 2006 16:10:14 GMT
    [ http://issues.apache.org/jira/browse/BEEHIVE-1135?page=comments#action_12425554 ] 
            
Carlin Rogers commented on BEEHIVE-1135:
----------------------------------------

Just wanted to add that using jsp tag files instead of jsp:includes will work and not have
this
problem. Possible workaround for folks waiting to pick up this fix.

> 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