Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: EE-1.8.2.GA_P04
-
Fix Version/s: EE-1.8.2.GA_P05
-
Component/s: Enterprise Push Server
-
Labels:None
-
Environment:WebLogic Server, ICEfaces, EPS
Description
When using WebLogic ARP support in EPS, it is possible that a deadlock can occur.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
The EPS' SessionContext class holds a lock for each ICEfaces ID. Both TomcatAdaptingServlet (Tomcat ARP) and WebLogicAdaptingServlet (WebLogic ARP) use this lock on a per ICEfaces ID basis as well as the EPS' SessionManager upon receiving Updated Views. However, down the chain the Tomcat ARP and WebLogic ARP support implementation also use a lock on the sessionMap, which is contained in the EPS' SessionManager. The EPS' SessionManager itself also uses both locks when receiving Updated Views, but in the opposite order. This can lead to a deadlock. I changed the order in the EPS' SessionManager's sendUpdatedViews() method as both locks are used in that method itself instead of somewhere down the chain. Marking this one as FIXED.
Show
Jack Van Ooststroom
added a comment - The EPS' SessionContext class holds a lock for each ICEfaces ID. Both TomcatAdaptingServlet (Tomcat ARP) and WebLogicAdaptingServlet (WebLogic ARP) use this lock on a per ICEfaces ID basis as well as the EPS' SessionManager upon receiving Updated Views. However, down the chain the Tomcat ARP and WebLogic ARP support implementation also use a lock on the sessionMap, which is contained in the EPS' SessionManager. The EPS' SessionManager itself also uses both locks when receiving Updated Views, but in the opposite order. This can lead to a deadlock. I changed the order in the EPS' SessionManager's sendUpdatedViews() method as both locks are used in that method itself instead of somewhere down the chain. Marking this one as FIXED.
Sending src/org/icefaces/push/server/SessionManager.java
Transmitting file data .
Committed revision 32289.