Win a copy of The Way of the Web Tester: A Beginner's Guide to Automating Tests this week in the Testing forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic


Ruprict J. Hollingsfeld
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am researching an issue we are experiencing in the development of an enterprise J2EE system, and am not finding much information via the usual channels.

Our team is observing through profiling a large number (many thousands) of instances of sun.reflect.DelegatingClassLoader in our application, which is causing significant issues during GC operations under a particular JDK. Our research indicates instances of DelegatingClassLoader are associated primarily with reflection, which our application utilizes quite heavily via hibernate, webwork, dynamic proxies, custom caching, etc.

Over 100+ iterations of our automatic test suite, with no container restarts or redeploys, we are observing an increase in the number of instances to approximately 20,000, at which point they appear to level off and remain relatively constant for subsequent test runs. Our profiling indicates this large number of instances on every JDK we test against; however, we are seeing GC performance bottlenecks with only one JDK.

Our primary concern is a lack of information about the nature of DelegatingClassLoader. Based on the limited info we've been able to gather, we have no way of knowing whether or not this number of instances is 'the norm' in an application this size or if we are experiencing a classloader leak. We are interested in any info or experiences the community has regarding reflection class loading in medium-to-large j2ee apps.

Thanks in advance!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic