axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Molettiere <pie...@axonstudios.net>
Subject Re: [jira] Commented: (AXIS-1771) Excessive Memory Use During Serialization/Deserialization
Date Wed, 19 Jan 2005 19:15:55 GMT

Thank you all for looking into this issue. Your attention is greatly  
appreciated.

On Jan 19, 2005, at 7:16 AM, Venkat Reddy (JIRA) wrote:
>      [  
> http://issues.apache.org/jira/browse/AXIS-1771? 
> page=comments#action_57774 ]
>
> Venkat Reddy commented on AXIS-1771:
> ------------------------------------
> [snip]
> I also see some deep recursion among -
>
> MessageElement.publishToHandler -> SAX2EventRecorder.replay ->  
> DeserializationContext.startElement -> BeanDeserializer.startElement  
> -> DeserializerImpl.startElement -> publishToHandler, and it starts  
> all over again.
>
> Its not an infinite loop, but it goes pretty deep in the call frames  
> and lot of object arrays are being allocated, and most of the  
> processing time is being spent here.
>
> Did anybody have insights into this area of the code?

Venkat:

My understanding of the call stack you're asking about, which I've  
mainly cobbled together from trying to figure out how to write a  
Serializer/Deserializer pair, is that for a given object graph, say:

root
   - A
      - 1
      - 2
   -B
      - 3
      - 4

For each node in the tree there is both a MessageElement and a  
Deserializer instance. The entire tree shares a single  
DerserializationContext. So what you're seeing is something like this;

root(MessageElement.publishToHandler)->SAX->DeserContext- 
 >root(BeanDeser.startElement)->root(DeserImpl.startElement [a call to  
super.startElement() from the BeanDeserializer)->

A(MessageElement.publishToHandler)->SAX->DeserContext- 
 >A(BeanDeser.startElement)->A(DeserImpl.startElement [a call to  
super.startElement() from the BeanDeserializer)->

1(MessageElement.publishToHandler)->SAX->DeserContext- 
 >1(BeanDeser.startElement)->1(DeserImpl.startElement [a call to  
super.startElement() from the BeanDeserializer)->

[insert endElement calls for 1 here]

2(MessageElement.publishToHandler)->SAX->DeserContext- 
 >2(BeanDeser.startElement)->2(DeserImpl.startElement [a call to  
super.startElement() from the BeanDeserializer)->

[insert endElement calls for 2 here]
[insert endElement calls for A here]

B(MessageElement.publishToHandler)->SAX->DeserContext- 
 >B(BeanDeser.startElement)->B(DeserImpl.startElement [a call to  
super.startElement() from the BeanDeserializer)->

3(MessageElement.publishToHandler)->SAX->DeserContext- 
 >3(BeanDeser.startElement)->3(DeserImpl.startElement [a call to  
super.startElement() from the BeanDeserializer)->

[insert endElement calls for 3 here]

4(MessageElement.publishToHandler)->SAX->DeserContext- 
 >4(BeanDeser.startElement)->4(DeserImpl.startElement [a call to  
super.startElement() from the BeanDeserializer)->

[insert endElement calls for 4 here]
[insert endElement calls for B here]
[insert endElement calls for root here]

This means that for my little seven node graph, there are 7  
MessageElement instances, 7 Deserializer instances, and a Deser Context  
instance. That's 15 objects to deserialize 7 nodes. And I think that  
each MessageElement may also have other things like RPCParams and  
RPCMessageElements, etc, although my understanding of what's happening  
there is pretty thin. Maybe those are just interfaces implemented by  
MessageElement.


--
Peter Molettiere
Senior Engineer
Truereq, Inc.
http://www.truereq.com/


Mime
View raw message