[ 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
