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=11307>. 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=11307 Deadlock in ClassLoader ------- Additional Comments From [EMAIL PROTECTED] 2002-08-08 21:47 ------- Sorry, I was a bit short in my last message... I was just dismayed that the bug was being marked as "resolved" despite the documentation to the contrary. Anyway, you're right, the Threads are trying to lock different objects. The problem is that each Thread has already locked what the other Thread now wants to lock. Looking at the stack traces, you'll see: "Thread-4" at WebappClassLoader.java:1660 is trying to lock object "0x33b3b78" (a org.apache.catalina.loader.ResourceEntry) but "task" has already locked that object at WebappClassLoader.java:1661. Likewise, "task" at ClassLoader.java:530 wants to lock object "0x2d965c8" (a org.apache.catalina.loader.WebappClassLoader), but "Thread-4" has already locked that object at ClassLoader.java:310. (Aside: I agree, threaded deadlocks are notoriously hard to reproduce. Generally I end up having to examine the stacks and audit the code to find out what went wrong. Given that I'm not familiar with the Catalina code, don't have an environment set up to work on it, and am desparately trying to meet a deadline at work, I just have to apologize profusely for not being able to help right now. But please let me know if I can explain anything else that would help you navigate the deadlock information.) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
