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?

--Peter

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



Reply via email to