axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Molettiere <>
Subject Re: Streaming SOAP and Faults
Date Sat, 15 May 2004 22:56:44 GMT

Hey guys,

A quick question.

Buffering the output might not be as memory intensive as building an 
in-memory representation of the stream, so there is probably something 
to be gained in streaming the response to a buffer.

In our application, we find that serializing our SOAP response causes 
OOM exceptions during serialization. We were miffed at first when we 
saw this, and it took a long time to track into the axis serialization 
code. The final message size isn't very large -- the XML encoded 
representation of our object graph is about 32k. The SOAP size is 
obviously much larger.

In profiling, though, we see lots of transient object creation in the 
process of serializing the message. Wouldn't streaming the message into 
a buffer help to reduce this memory inefficiency?


On May 15, 2004, at 3:38 PM, Aleksander Slominski wrote:

> Mark Ericson wrote:
>> Nelso, streaming SOAP is certainly a good idea for addressing some
>> scalability issues.  However it also introduces an interesting 
>> challenge.
>> Say you have a service that processes some input and starts streaming
>> output immediately.   As it is generating the response SOAP message 
>> every
>> byte that is output goes almost immediately to the wire (ignoring 
>> caching
>> and/or framing for a second).  Now say sometime into the result an 
>> error
>> occurs, a database exception, or perhaps a problem in the input 
>> stream, oops!
>> The result SOAP stream has already commited itself to be a SOAP body, 
>> it
>> can no longer turn itself into a fault because those bytes have gone 
>> out
>> over the wire.
>> What to do!?  In some ways it would have been nice if the SOAP 
>> protocol
>> had put the fault at the end rather than the beginning (SOAP footers?)
>> SOAP 1.2 seems to allow a SOAP fault to appear within a child of the 
>> body,
>> but then states "the element has no SOAP-defined semantics"
>> There are certainly problems I would also like to use streaming for, 
>> but
>> what to do about faults?
> Mark,
> i raised this problem multiple times in past. the only reliable and 
> interoperable solution i know is to buffer whole output :(
> alek
> -- 
> The best way to predict the future is to invent it - Alan Kay

View raw message