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
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
