Re: [jira] Commented: (AXIS-1771) Excessive Memory Use During Serialization/Deserialization

[Peter Molettiere]

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/