axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chuck Williams (JIRA)" <j...@apache.org>
Subject [jira] Created: (AXIS2-4957) ServiceTCCL composite breaks class caching in java reflection, jboss serialization, ...
Date Sat, 12 Feb 2011 21:53:57 GMT
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


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-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message