[jira] Resolved: (BEEHIVE-1135) NetUI deadlock condition for concurrent requests to an action and a JSP with a JSP include

["Carlin Rogers (JIRA)" <de...@beehive.apache.org>]

     [ 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