axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srinath Perera <>
Subject Re: [Axis2] Memory usage in generated code
Date Thu, 29 Dec 2005 12:51:54 GMT
Hi Dims;

May be we can handle this by having a constructor like

public OMElement(ADBBean){


That just keep ADBBean and do not build the Tree unless the element is
accessed. And we can have the write*(..) methods overidden so it can
directly write ADBBean.

I am thinking about something like

public ADBOMElement{
       private OMElement delegate = null;
       private ADBBean bean = null;

      public ADBOMElement ADBBean bean(){
                this.bean = bean;

    public writeXX(.....){
         if(delegate == null){

   //all other methods
   public X xxx(){
        if(delegate == null){
             delegate = buildOMfromADBBean(bean);



On 12/27/05, Davanum Srinivas <> wrote:
> Ajith, Eran,
> I'd like bounce this issue off of you to see what you think. There
> generated code has the following construct. Am trying ADB databinding
> with WSDL2Java and looking at the generated stub.
>         org.apache.axis2.soap.SOAPEnvelope env;
>         env = createEnvelope();
>         setValueDoc(env, toOM(param10));
> param10 is of course a ADBBean and hence the code gets pull parser
> from the bean to construct an OMElement. At this point we still
> haven't constructed the whole OM tree for param10. Yes, we have to
> defer that till the last minute. But what happens is setValueDoc has
> the following code
>                 body.addChild(value);
> where the value is OMElement created by toOM. When it gets added to
> the soap body (inside soap envelope), it ends up calling detach on
> value. detach() forces a build of the whole OM tree, so at this point
> we have the original data structure AND the whole OM tree. This takes
> up a large chunk of memory.
> Could you please help me to do the following? basically we should not
> have to build the OM tree. we need to hook up param10's pull parser to
> soap envelope such that when we serialize the soap envelope (to the
> stream) only then the pull events are generated from the beans. and
> even then they should not be cached as we are writing directly to the
> stream.
> Am making good progress with leaks and memory. The
> getXMLStreamWithoutCaching change itself allowed me to send 200000
> strings (instead of 100000) w/o causing OutOfMemoryExceptions, however
> this one is a biggie and i need your help :)
> thanks,
> dims
> --
> Davanum Srinivas :

View raw message