On Fri, Jul 27, 2012 at 12:02 PM, Kyle R. Burton <kyle.bur...@gmail.com> wrote: > I encountered a deadlock on one of our production systems (one out of > 3) last night. Looking at a thread dump of the JVM, there are several > (over 200) threads that are all waiting on a > java.util.concurrent.locks.ReentrantLock from Keyword.intern. > > I've put up the thread dump and information about the os and jvm versions > here: > > https://github.com/relaynetwork/20120727-deadlock-issue > > The part of our application that deadlocked is a web service that uses > Compjure and Jetty. Other parts of the application did not deadlock > (we have AMQP consumers that were still processing successfully). > > I have since restarted the service and it is processing again. I'm > not sure what to look at next, can anyone suggest a next step for > determining the cause?
I think you're hitting a bug in Java. Specifically, this one: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6822370 It looks like there are 237 threads attempting to call java.util.concurrent.ConcurrentHashMap$Segment.put, which makes the lock awfully contentious. But the problem is that they all decided to park themselves. That's a sure sign that the view of memory is inconsistent across the processors. Looking at the evaluation of the bug, that seems to be exactly the problem. It was supposedly fixed in 1.6.0_19, but there seem to be reports that it's still present in _20 and _21. It's not all bad news though. It seems like a workaround is to use "-XX:+UseMembar". -John -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
