You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Basavaraja U T <ba...@huawei.com> on 2009/12/04 05:33:52 UTC

RE: High memory usage with web service registration

Hi Dan,

XFire has provided a mechanism to re-use the JAXBContext across different
web service publishing.

The Bug Id - XFIRE-669. (http://jira.codehaus.org/browse/XFIRE-669)

Seems it lets us to pass an existing JAXBContext to a JaxbServiceFactory.
The context is then used by all layers from there. i.e. we can construct one
JAXBContext object with all the ObjectFactory.class'es from wsdl2java tool
generated java files and re-use the JAXBContext object for multiple web
service publishing.

It helps to reduce the memory usage if there is large no. of related web
services (like MTOSI solution, which has around 30-40 interfaces) are
published by an application.

It would be great if such a mechanism is provided by CXF also.

With regards,
Basava

****************************************************************************
***********
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org] 
Sent: Wednesday, November 18, 2009 1:37 AM
To: users@cxf.apache.org
Cc: Basavaraja U T
Subject: Re: High memory usage with web service registration



In a way, I'm not exactly surprised by this.  I just tried debugging some of

the annotation stuff in the JRE and annotations are stored in
LinkedHashMaps.   
Those hashmaps are definitely not the most  memory efficient, especially for

cases where there are only one or two annotations.   Only Sun/Oracle can do 
much about that.

JAXB COULD probably not output annotations in cases where the defaults would

match what the annotation is setting anyway.  That could be an enhancement 
request to them.    You could possibly even write an XJC plugin that would 
remove the annotations in the places where they aren't needed.   That could 
help.

I'm really not sure what else to suggest.  You COULD create a list of ALL
the 
jaxb generated classes in all the services and configure them as extra 
classes.   Thus, every service would create their jaxb context based on all 
the classes.   We detect when they are the same and allow the services to 
share a JAXB context instead of creating a new one.   However, that would 
allow the services to "know" more than they really should.

Dan


On Tue November 17 2009 2:40:06 am Basavaraja U T wrote:
> Hi All,
> 
> 
> 
> I am facing a high memory usage problem with web service registration when
> wsdl has lots of simple and complex type definitions. I am using
> jaxb(default) databinding and memory usage is quite high, it is in the
>  range of 2 to 8 MBs for each of the web service registration. I have
>  around 20 web services in an application and total memory usage for web
>  services registration alone is taking more than 60 MB!.
> 
> 
> 
> I observed the behavior with cxf 2.2 and cxf 2.3 on Windows XP.
> 
> I observed there were lots of annotations in java files generated from
> wsdl2java. When these annotations were removed(for testing), the memory
> usage was drastically less.
> 
> 
> 
> Is there any way to reduce/optimize the memory usage?
> 
> Is there any optimizations with respect to annotations/binding generated
by
> wsdl2java.
> 
> 
> 
> With regards,
> 
> Basava
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog


Re: High memory usage with web service registration

Posted by Daniel Kulp <dk...@apache.org>.
Actually, looking at the code, you may already be able to do this.   The 
JAXBDataBinding has a constructor of:

JAXBDataBinding(JAXBContext context)

Thus, via config or similar, you should be able to setup your own 
JAXBDataBinding object using a preconfigured JAXBContext.     Not sure how 
well tested that is though.

Dan



On Thu December 3 2009 11:33:52 pm Basavaraja U T wrote:
> Hi Dan,
> 
> XFire has provided a mechanism to re-use the JAXBContext across different
> web service publishing.
> 
> The Bug Id - XFIRE-669. (http://jira.codehaus.org/browse/XFIRE-669)
> 
> Seems it lets us to pass an existing JAXBContext to a JaxbServiceFactory.
> The context is then used by all layers from there. i.e. we can construct
>  one JAXBContext object with all the ObjectFactory.class'es from wsdl2java
>  tool generated java files and re-use the JAXBContext object for multiple
>  web service publishing.
> 
> It helps to reduce the memory usage if there is large no. of related web
> services (like MTOSI solution, which has around 30-40 interfaces) are
> published by an application.
> 
> It would be great if such a mechanism is provided by CXF also.
> 
> With regards,
> Basava
> 
> ***************************************************************************
> * ***********
> This e-mail and attachments contain confidential information from HUAWEI,
> which is intended only for the person or entity whose address is listed
> above. Any use of the information contained herein in any way (including,
> but not limited to, total or partial disclosure, reproduction, or
> dissemination) by persons other than the intended recipient's) is
> prohibited. If you receive this e-mail in error, please notify the sender
>  by phone or email immediately and delete it!
> 
> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org]
> Sent: Wednesday, November 18, 2009 1:37 AM
> To: users@cxf.apache.org
> Cc: Basavaraja U T
> Subject: Re: High memory usage with web service registration
> 
> 
> 
> In a way, I'm not exactly surprised by this.  I just tried debugging some
>  of
> 
> the annotation stuff in the JRE and annotations are stored in
> LinkedHashMaps.
> Those hashmaps are definitely not the most  memory efficient, especially
>  for
> 
> cases where there are only one or two annotations.   Only Sun/Oracle can do
> much about that.
> 
> JAXB COULD probably not output annotations in cases where the defaults
>  would
> 
> match what the annotation is setting anyway.  That could be an enhancement
> request to them.    You could possibly even write an XJC plugin that would
> remove the annotations in the places where they aren't needed.   That could
> help.
> 
> I'm really not sure what else to suggest.  You COULD create a list of ALL
> the
> jaxb generated classes in all the services and configure them as extra
> classes.   Thus, every service would create their jaxb context based on all
> the classes.   We detect when they are the same and allow the services to
> share a JAXB context instead of creating a new one.   However, that would
> allow the services to "know" more than they really should.
> 
> Dan
> 
> On Tue November 17 2009 2:40:06 am Basavaraja U T wrote:
> > Hi All,
> >
> >
> >
> > I am facing a high memory usage problem with web service registration
> > when wsdl has lots of simple and complex type definitions. I am using
> > jaxb(default) databinding and memory usage is quite high, it is in the
> > range of 2 to 8 MBs for each of the web service registration. I have
> > around 20 web services in an application and total memory usage for web
> > services registration alone is taking more than 60 MB!.
> >
> >
> >
> > I observed the behavior with cxf 2.2 and cxf 2.3 on Windows XP.
> >
> > I observed there were lots of annotations in java files generated from
> > wsdl2java. When these annotations were removed(for testing), the memory
> > usage was drastically less.
> >
> >
> >
> > Is there any way to reduce/optimize the memory usage?
> >
> > Is there any optimizations with respect to annotations/binding generated
> 
> by
> 
> > wsdl2java.
> >
> >
> >
> > With regards,
> >
> > Basava
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog