[ 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
