SPR-4876 [Performance] CachedIntrospectionResults initialization slow down weblogic. [SPR-7838]

[spring-projects-issues]

David.Turing opened SPR-7838 and commented

I have a key customer that widely use Spring(they do some repackage by themself).
Spring version is : 1.2.x
JDK version is : 1.4.2_15, and now, they are suffering from issue describe in #9552.

From the threaddump, we see lots of thread are stucked as below:
"ExecuteThread: '7' for queue: 'weblogic.kernel.Default'" id=16 idx=0x54 tid=24953 prio=5 alive, in native, blocked, daemon

• Blocked trying to get lock: java/lang/Class@0x2e494da0[fat lock]
  at jrockit/vm/Threads.waitForUnblockSignal()V(Native Method)
  at jrockit/vm/Locks.fatLockBlockOrSpin(Locks.java:1630)
  at jrockit/vm/Locks.lockFat(Locks.java:1731)
  at jrockit/vm/Locks.monitorEnterSecondStage(Locks.java:1277)
  at jrockit/vm/Locks.monitorEnter(Locks.java:2389)
  at java/beans/Introspector.findExplicitBeanInfo(Introspector.java:404)
  at java/beans/Introspector.<init>(Introspector.java:355)
  at java/beans/Introspector.getBeanInfo(Introspector.java:157)
  at org/springframework/beans/CachedIntrospectionResults.<init>(CachedIntrospectionResults.java:137)
  at org/springframework/beans/CachedIntrospectionResults.forClass(CachedIntrospectionResults.java:78)
  at org/springframework/beans/BeanWrapperImpl.setWrappedInstance(BeanWrapperImpl.java:190)
  at org/springframework/beans/BeanWrapperImpl.<init>(BeanWrapperImpl.java:168)
  .....

And we see another thread block them as below(note that unlocked means a Biased Lock Strategy:

"ExecuteThread: '12' for queue: 'weblogic.kernel.Default'" id=21 idx=0x68 tid=24958 prio=5 alive, in native, blocked, daemon

• Blocked trying to get lock: sun/misc/Launcher$AppClassLoader@0x2efd9520[unlocked]
  at jrockit/vm/Threads.waitForUnblockSignal()V(Native Method)
  at jrockit/vm/Locks.fatLockBlockOrSpin(Locks.java:1630)
  at jrockit/vm/Locks.lockFat(Locks.java:1731)
  at jrockit/vm/Locks.monitorEnterSecondStage(Locks.java:1277)
  at jrockit/vm/Locks.monitorEnter(Locks.java:2389)
  at sun/misc/Launcher$AppClassLoader.loadClass(Launcher.java:260)
  at java/lang/ClassLoader.loadClass(ClassLoader.java:282)
  ^-- Holding lock: weblogic/utils/classloaders/GenericClassLoader@0x23314a58[thin lock]
  at java/lang/ClassLoader.loadClass(ClassLoader.java:282)
  ^-- Holding lock: weblogic/utils/classloaders/GenericClassLoader@0x2edfabb0[thin lock]
  at java/lang/ClassLoader.loadClass(ClassLoader.java:282)
  ^-- Holding lock: weblogic/utils/classloaders/GenericClassLoader@0x2e4e1428[thin lock]
  at java/lang/ClassLoader.loadClass(ClassLoader.java:235)
  at weblogic/utils/classloaders/GenericClassLoader.loadClass(GenericClassLoader.java:224)
  at java/beans/Introspector.instantiate(Introspector.java:1455)
  at java/beans/Introspector.findExplicitBeanInfo(Introspector.java:406)
  ^-- Holding lock: java/lang/Class@0x2e494da0[fat lock]
  at java/beans/Introspector.<init>(Introspector.java:355)
  at java/beans/Introspector.getBeanInfo(Introspector.java:157)
  at org/springframework/beans/CachedIntrospectionResults.<init>(CachedIntrospectionResults.java:137)
  at org/springframework/beans/CachedIntrospectionResults.forClass(CachedIntrospectionResults.java:78)
  at org/springframework/beans/BeanWrapperImpl.setWrappedInstance(BeanWrapperImpl.java:190)
  at org/springframework/beans/BeanWrapperImpl.<init>(BeanWrapperImpl.java:168)

Yes, we guess we are hit the #9552. CachedIntrospectionResults initialization make weblogic server slow down and sometimes crash, depend on how much threads are running into ClassLoader.loadClass.

Most often, we had to throttle the threads number that running into this case.

We hope that juergen could provide a fix for the customer, both on Spring 1.2.9 and Spring 2.5.5, in addtion to the Spring 3.0, because the latter is not yet certified on WebLogic 11g container.(I will ask michael.chen for advice, later).

Thanks and Regards

David.Turing
Oracle Fusion Middleware Department
Advance Customer Support

---

Affects: 1.2 final, 2.5.4

This issue is a sub-task of #9552

[spring-projects-issues]

Juergen Hoeller commented

Thomas, could you take over here - in particular with respect to what we can do about workarounds for Spring 1.x/2.x?

As for the issue itself, I'm not sure what we can do about this in the Spring codebase since it is the JavaBeans Introspector performing its BeanInfo class search there. We cannot easily suppress this - not as long as we keep using the Introspector. Getting rid of the Introspector is an option and has been discussed before; however, we can only actually consider this for a future major Spring release due to compatibility implications...

Juergen

[spring-projects-issues]

Rossen Stoyanchev commented

This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug.

There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it.

If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description.

We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.