axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Srinath Perera <hemap...@gmail.com>
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){
                 writeADBBean(.....)
          }else{
                 delegate.write(...........);
          }
   }

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


}

Thanks
Srinath


On 12/27/05, Davanum Srinivas <davanum@gmail.com> 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 : http://wso2.com/blogs/
>

Mime
View raw message