Revisiting the Proposal for fixing out-of-memory error JIRA axis2-2968

[Ann Robinson <ro...@us.ibm.com>]

Hi, all,
I have updated the proposed fix for the out-of-memory error that occurs on
the server in some environments, and I would be interested in getting some
feedback on the updated proposal.

Some background:
----------------
This out-of-memory (OOM) error happens on the server in some environments
where there is
a large number of applications.

At deployment time, when the applications are loaded, the AxisService
objects are created.
For those applications where the loading ends up invoking the
WSDL11ToAxisServiceBuilder,
the wsdl is read in and saved as a Parameter on the AxisService object.  As
the applications
are loaded, an OOM happens before requests start flowing.

In analyzing the java heap dumps, one of the biggest consumers of memory
is with the wsdl4j WSDLDefinition objects.  The heap dump indicates that
the WSDLDefinition uses the xerces dom for underlying support, particularly
for schemas.  This makes the WSDLDefinition very heavy-weight.

The heap dump also shows that the WSDLDefinition objects of concern are the
ones being saved in the AxisService object's ParameterInclude
list.  Comments in
the code (WSDL11ToAxisServiceBuilder) indicate that this is done so that,
if
some component needs to utilize the WSDLDefinition, the component can
access
it via a Parameter in the AxisService object.

The initial proposed fix was to use a light-weight wrapper on the WSDL4J's
WSDL definition
object in order to release resources and reload WSDL if needed. Prototypes
of this fix
did resolve the OOM. This solution, however, had drawbacks with repect to
custom WSDL locators
and ?WSDL support.


Updated Proposed Fix:
---------------------

I have been working with the WSDL4J team on ways to reduce the memory
footprint
of the WSDL definition implementation.  This means that a newer version of
WSDL4J
will need to be picked up by AXIS2 when the updated WSDL4J becomes
available.

In the meantime, for Axis2, I would like to propose using a wrapper on the
WSDL4J's WSDLDefinition object for the following reasons:
         - to keep changes to the WSDL4J implementation from impacting
users
           (especially those components that expect to access a
WSDLDefinition
            from the parameter include list in the AxisService)
         - to allow certain environments to take advantage of changes in
WSDL4J,
           (eg. new APIs, new steps, or catch exceptions) to reduce memory
footprint
         - to have the option of doing an intermediate solution for certain
environments
           while preserving current behavior of the Axis2 kernel for the
rest of the
           environments

The difference in this solution from the previously proposed solution is
that
         - no resources will be released
         - no need to try to reload the original WSDL (so we don't have to
worry about
            custom WSDL locators or ?WSDL support)

This wrapper on the WSDLDefinition would do the following:
         - implement the wsdl definition interface and delegate the methods
to the actual
           WSDL4J wsdl definition implementation that is being wrapped
         - provide tracing for debug situations
         - perform new steps to reduce memory footprint only when needed
for certain environments
                - - this could be controlled via a configuration parameter
so that the default
                     behavior is the same as current behavior
                - - this could include serializing/deserializing the
WSDL4J's WSDLDefinition
                     object if the WSDLDefinition can be serialized


Comments?
- Thanks, Ann