A Java Thread deadlock has occured [SPR-9837]

[spring-projects-issues]

Jeff Sanders opened SPR-9837 and commented

"http-0.0.0.0-8080-7":at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:184) - waiting to lock <455368173> (a java.util.concurrent.ConcurrentHashMap@1b245ded ) which is held by http-0.0.0.0-8080-4

The above error happens a few times and stops the Web App from processing. We have to restart JBoss to get the app back up and processing requests.

---

Affects: 3.2 M1, 3.2 M2

Attachments:

• deadlock info Document1.txt (1.94 kB)

Issue Links:

• Performance bottleneck and potential thread deadlock in DefaultSingletonBeanRegistry [SPR-8471] #13117 Performance bottleneck and potential thread deadlock in DefaultSingletonBeanRegistry ("duplicates")

0 votes, 5 watchers

[spring-projects-issues]

Juergen Hoeller commented

Does that happen for threads obtaining non-singleton beans? Or for lazy-init singleton beans?

Juergen

[spring-projects-issues]

Jeff Sanders commented

Hello Juergen and thanks for getting in touch with me on this.

My answer would be no Juergen, I've only seen the following two types of deadlock:

1. at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:184) - waiting to lock <455368173> (a java.util.concurrent.ConcurrentHashMap@1b245ded )

2. at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinitionNames(DefaultListableBeanFactory.java:297) - waiting to lock <2108923244> (a java.util.concurrent.ConcurrentHashMap@7db39d6c ) which is held by http-0.0.0.0-8080-1 - locked <455368173> (a java.util.concurrent.ConcurrentHashMap@1b245ded) - locked <455368173> (a java.util.concurrent.ConcurrentHashMap@1b245ded)
   RemoveMark Read1487222670

Thanks

Jeff Sanders
443 254 1426

[spring-projects-issues]

Dennis Kieselhorst commented

Seems to be related to #13117

[spring-projects-issues]

Juergen Hoeller commented

I'm pretty sure this effectively refers to the same issue as addressed in #13117...