axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Suriarachchi" <amilasuriarach...@gmail.com>
Subject Re: [axis2] Revisiting the Proposal for fixing out-of-memory error JIRA axis2-2968
Date Thu, 20 Sep 2007 11:01:47 GMT
here is an another option for this problem.

we keep wsdl4j object structure in memory to show the wsdl file to the user
when they request with ?wsdl.

So if we can display the wsdl file without keeping the wsd4j definition then
there is not need to keep the
wsdl4j object and hence solve the problem.

Here is the way I suggest to display the wsdl.

For the moment wsdl file is kept in the aar file and here I am suggesting to
let users to keep them in a
seperate folder. This allows them to an directory hiarachy to manage the
wsdl files.

To get the wsdl location we can use two parameters.
1. wsdlBaseUri used in axis2.xml to keep the base uri location
2. wsdlFileLocation used in service.xml keep the exact wsdl location.

Here is the way.
When the first request comes ?wsdl, Axis2 redirect the request giving the
wsdl location
This is done by adding the wsdl file path to  the contextRoot and
serviceName.

i.e.
AxisService axisServce = (AxisService) serviceObj;
                        Parameter wsdlFileLocationParameter =
axisServce.getParameter("wsdlFileLocation");
                        if (wsdlFileLocationParameter != null){
                            String wsdlLocation = (String)
wsdlFileLocationParameter.getValue();
                            String redirectUrl = null;
                            if (configContext.getServiceContextPath
().endsWith("/")){
                                redirectUrl =
configContext.getServiceContextPath()
                                    + serviceName + "/" + wsdlLocation;
                            } else {
                                redirectUrl =
configContext.getServiceContextPath()
                                    + "/" + serviceName + "/" +
wsdlLocation;
                            }
                            res.sendRedirect(redirectUrl);

                        }

then when the requests come to show the wsdl and xsd files Axis2 can simply
append the file path to
the base uri and get that from the file system.

String uri = req.getRequestURI();
        String contextPath = configContext.getServiceContextPath();
        String servicePart = null;
        if (configContext.getServiceContextPath().endsWith("/")){
             servicePart = uri.substring(uri.indexOf(contextPath) +
contextPath.length());
        } else {
            servicePart = uri.substring(uri.indexOf(contextPath) +
contextPath.length() + 1);
        }
        String serviceName = servicePart.substring(0, servicePart.indexOf
("/"));
        String filePath = servicePart.substring(servicePart.indexOf("/") +
1);

        AxisService axisServce = configContext.getAxisConfiguration
().getService(serviceName);
        Parameter wsdlFileLocationParameter = axisServce.getParameter
("wsdlFileLocation");
        if (wsdlFileLocationParameter != null) {
            //i.e we have the wsdl file locator
            Parameter wsdlBaseUriParameter =
                    configContext.getAxisConfiguration
().getParameter("wsdlBaseUri");
            if (wsdlBaseUriParameter != null) {
                String wsdlBaseUri = (String) wsdlBaseUriParameter.getValue
();
                String fileToRead = wsdlBaseUri + filePath;
                // read and send the file
                InputStream fileInputStream = new
FileInputStream(fileToRead);
                if (fileInputStream != null) {
                    OutputStream out = res.getOutputStream();
                    res.setContentType("text/xml");
                    ListingAgent.copy(fileInputStream, out);
                    out.flush();
                    out.close();
                    return;
                }
            }
        }

I have attached the complete patch for the same jira.

This works fine when the wsdl file is viewed from the browser. Browsers can
handle redirect correctly.

The problem is when I try to generate the code for this using wsdl2java tool
it does not work since,
wsdl4j can not handle redirects properly.

if I give the url directly to the wsdl without using the ?wsdl it works
fine.

So if you can fix this issue(I don't know whether there is a configuration
for this) this would give much better performance.

Amila.

On 9/19/07, Amila Suriarachchi <amilasuriarachchi@gmail.com> wrote:
>
>
>
> On 9/19/07, Ann Robinson <robinsona@us.ibm.com> wrote:
> >
> >  Hi, all,
> > This is a re-send of the note with the correct [axis2] prefix in the
> > subject line.
> >
> > 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
> >
>
> what is the parameter you have used for that? As I saw in your patch you
> have changed the existing classes with out checking for a parameter.
> As I saw this change is effect to the ?wsdl and wsdl2java tool and
> wsdl11Axisservice builder at deployment time.
> does all these cases work properly with imports and includes?
> if these working features are preserved I am ok with this change.
>
>
>                 - - this could include serializing/deserializing the
> > WSDL4J's WSDLDefinition
> >                      object if the WSDLDefinition can be serialized
> >
> >
> > Comments?
> > - Thanks, Ann
> >
>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.




-- 
Amila Suriarachchi,
WSO2 Inc.

Mime
View raw message