Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@axis.apache.org
Date: Sat, 12 Feb 2011 23:57:57 +0000 (UTC)
From: "Chuck Williams (JIRA)" <jira@apache.org>
To: java-dev@axis.apache.org
Message-ID: 
 <997743160.13248.1297555077595.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <786272495.13202.1297547637509.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Updated: (AXIS2-4957) ServiceTCCL composite breaks class
 caching in java reflection, jboss serialization, ...
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/AXIS2-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chuck Williams updated AXIS2-4957:
----------------------------------

    Attachment: AXIS2-4957.patch

Patch to fix AXIS2-4957:

Cache composite ServiceTCCL so that it is reused rather than reconstructed for every web service
operation.  This is essential to ensure ClassLoader-indexed class-caching schemes work, e.g. that
in java reflection.

This is a purely performance change with no visible functional impact.  E.g., it ensures accessor
classes generated by java reflection are available for reuse, speeding up reflection by over 10x and
eliminating perm gen space garbage/bloat.  However, functionally, java reflection appears the same
whether it regenerates accessor classes every time (no caching) or reuses these classes (caching).

As there is no observable functional impact it is hard to verify the change with a junit test.  No
junit test included with this fix.


> 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
>         Attachments: AXIS2-4957.patch
>
>
> 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