[
https://issues.apache.org/jira/browse/AXIS2-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Williams reassigned AXIS2-4957:
-------------------------------------
Assignee: Chuck Williams
> ServiceTCCL composite breaks class caching in java reflection, jboss
> serialization, ...
> ---------------------------------------------------------------------------------------
>
> Key: AXIS2-4957
> URL: https://issues.apache.org/jira/browse/AXIS2-4957
> Project: Axis2
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.5.4, nightly
> Reporter: Chuck Williams
> Assignee: Chuck Williams
>
> Setting ServiceTCCL parameter to composite gives threads executing request
> operations access to classes loaded by either the default thread context
> class loader or the service class loader. AbstractMessageReceiver resets the
> thread's context class loader to a composite class loader that consults both
> of these sources on every invocation. The current code does this by
> constructing a new composite class loader every time. This has catastrophic
> performance consequences if the request-processing thread makes extensive use
> of java reflection or other class-caching mechanisms such as jboss
> serialization.
> Class caching in java reflection and generally other places is indexed to the
> class loader. By creating a new composite class loader for every request
> processed by a service, these requests get no class caching! This slows down
> java reflection, jboss serialization, etc., by over an order of magnitude and
> bloats perm gen space with unnecessary generated classes (java reflection
> accessor classes, jboss serialization ClassMetaData, etc.). New classes are
> generated for every request unnecessarily. The performance of java
> reflection in particular is dependent on effective caching of its generated
> accessor classes. In an actual axis2 application the bloat increased perm
> gen space from about 80 meg to over 2 Gig and java reflection accessor class
> regeneration became the primary performance bottleneck.
> The fix is simple: cache and reuse the composite ServiceTCCL.
> I'm testing a patch with the fix now and will upload when verified.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
