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
[email protected]
http://www.dankulp.com/blog

Reply via email to