On 10/10/18 23:04, Caldarale, Charles R wrote: >> From: Mark Thomas [mailto:ma...@apache.org] >> Subject: Re: Tomcat Clustering Support > >> Thread A is in the middle of processing a request. It is evaluating some >> EL which requires access to the view map which in turn causes the >> ViewMap to update the session. >> com.sun.faces.application.view.ViewScopeManager.processEvent locks the >> ViewMap object. It then tries to update the session. To do this it >> requires the session lock. Thread A is waiting for this lock. > > Assuming the ViewMap is used by multiple sessions, this locking order goes > against the usual protocol of more local before more global. Might be > possible to file a bug report with Mojarra, but given that the code appears > to be in a com.sun class, that might not get anywhere. > >> Thread B is at the end of a request. The session has been updated and it >> is attempting to write the updated session attributes to the cluster. >> The session lock has been obtained. The individual attributes are being >> written. The code has reached the ViewMap object. In order to write this >> object, the ViewMap object must be locked. Thread B is waiting for this >> lock. > > This is the generally the more desirable order.
I think ViewMap is per session but I haven't looked that closely at the code. >> Has anyone on the users list come across this problem before? If so, how >> have you solved it? Suggestions for alternative solutions also welcome. > > Can the thread doing the session synchronization lock the session, get a > shallow copy of the attributes, unlock the session, then process the > attributes? Not sure if that would maintain sufficient coherency. A variation of that might work but at the possible expense of generating rather more garbage. The changes to the session are stored in a DeltaRequest. Currently the sequence is: - lock session - serialize DeltaRequest to message - recycle DeltaRequest - unlock session - send message Change that to: - lock session - keep reference to populated DeltaRequest - provide session with new DeltaRequest object - unlock session - serialize populated DeltaRequest to message - send message and this deadlock should be resolved. To avoid the expense of creating a new DeltaRequest each time, a pool of them could be used which should minimise the garbage. Looking at the sequence of events, I don't think this does much that is likely to harm coherence. If folks think this looks reasonable, I can create a BZ enhancement request to implement it. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
