DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15060>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15060 deadlock in ResourceLimitingPool [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED ------- Additional Comments From [EMAIL PROTECTED] 2002-12-09 09:25 ------- (Filling in discussion on Avalon-dev. Messages are chronologically from top to bottom.) Peter, if the deadlock happens inside the ClassLoader, you must synchronize on *all* objects that may access that CL instance. For example, consider this: class Callee { /** * This method should be synchronized, but due to a bad coder, * it isn't. If two threads enter it, it will deadlock. */ public void willDeadlockIfCalledConcurrently (); } class Caller { private Callee callee; public Caller (Callee callee) { this.callee = callee; } public synchronized doStuff () { callee.doStuff (); } } Callee callee = new Callee (); Caller callerA = new Caller (callee); Caller callerB = new Caller (callee); OK, since both callerA and callerB use the same callee, it doesn't matter that the doStuff method is synchronized. When callerA.doStuff is entered, callerA is locked. But this does not prevent a thread from entering callerB.doStuff. The same problem exist here - the deadlock is in the classloader, meaning that we must have a mutex for *all* access paths to the CL instance. I'm not convinced that your patch does that. Could you provide some argument for it? I'm not being critical of your patch, it's just that I'm wary of adding a patch that may not solve the problem (we end up with 10+ patches before finally solving the problem, and are left to wonder just which one of them really did solve it). ----------------------------------------------------------------------------- From: Peter Donald It does not solve it - just makes it less likely to happen. As most JVMs resolve .class files on load nowadays - especially with things like hotspot. Thus the main access to classloader occurs on initial class load.The ClassLoader mechanism is relatively thread-safe except when one thread becomes re-enters classloader (ie ClassLoader.loadClass() --> static initializer block --> ClassLoader.loadClass()) and another thread is in classloader. I vaguely recall seeing the detailed explanation somewhere but can't for the life of me remember where. Anyways the patch does not solve it but it will hopefully make it less likely occurence. ------------------------------------------------------------------------------ From: Leo Sutic Peter, take a look at this: http://developer.java.sun.com/developer/bugParade/bugs/4699981.html Deadlock in the classloader loading, with out circular locking Category java:runtime Reported Against 1.4.0_02, hopper-rc Release Fixed 1.4.0_03, 1.4.1_02, mantis-beta I noted that Harald was running 1.4.1_01. This bug looks just like his, and it is fixed in 1.4.1_02. ------------------------------------------------------------------------------ From: Peter Donald Thats precisely the bug and precisely where I saw it before ;) I would put in the "fix" and just note that it is there to fix buggy JVMs. ------------------------------------------------------------------------------ From: Leo Sutic Harald, can you try your app with 1.4.1_02? Peter, if this is a bug that appears only on 1.4.1_01, I'd rather not apply the patch. It doesn't fix the bug, and in addition, the synchronization only occurs in newInstance(), but before entering that method, the m_semaphore is already locked: /** * Create a new poolable instance by by calling the newInstance method * on the pool's ObjectFactory. (...) * This method is only called by threads that have m_semaphore locked. */ protected Poolable newPoolable() throws Exception Thus, you will never wait on that monitor as access is already serialized. (It is thus guaranteed to not fix the bug.) The fix would be to upgrade to 1.4.1_02. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
