start
processing results
before the server has completed generating them.
this is less of concern when you do async communication right?
thanks,
alek
From:
Brian Abbott [mailto:[EMAIL PROTECTED]]
Sent: Saturday, May
15, 2004 6:18
PM
To:
[EMAIL PROTECTED]
Subject: Re: St
would have been nice if the requestor could start processing results
before the server has completed generating them.
- Mark
From: Brian Abbott [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 15, 2004 6:18
PM
To: [EMAIL PROTECTED]
Subject: Re: Streaming SOAP and
Faults
It
would have been nice if the requestor could start processing results
before the server has completed generating them.
- Mark
From: Brian Abbott [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 15, 2004 6:18
PM
To: [EMAIL PROTECTED]
Subject: Re: Streaming SOAP and
Faults
It
For 20 megabyte messages, buffering to disk is also a reasonable option.
Dima has made some improvements since the 1.2 beta release to
performance as well.
Brian Abbott wrote:
If you where to do that, I dont think it's any longer considered
"streaming", is it?
yes. as you baffer it is no longer streaming serialization.
but you can still do streaming parsing ...
alek
Brian Abbott
Aleksander Slominski wrote:
Mark Ericson wrote:
Nelso, streaming SOAP i
Not technically -- but if it will handle larger message sizes with the
constraints set by the SOAP specification with regards to fault
handling, then it is a step in the right direction.
--Peter
On May 15, 2004, at 3:40 PM, Brian Abbott wrote:
If you where to do that, I dont think it's any longe
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 e
If you where to do that, I dont think it's any longer considered
"streaming", is it?
Brian Abbott
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
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
>There are certainly problems I would also like to use streaming for, but
>what to do about faults?
That's a really good question.
The more I get into SOAP, the more really good questions like that
come up.
It seems that if an exception is thrown, the stream should stop at that
point. So, now you've transmitted an incomplete message. It seems that
if you want to avoid making major modifications to SOAP, you would need
to send a fault message immediately following that would in some way
reference t
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
12 matches
Mail list logo
