S
Steve Schuler
Hello all - I'm working an a SoapExtension to implement the SOAP with
Attachments protocol.
Here's a Google thread from the MS newsgroups from two years ago that frames
the design issue mentioned in the Subject:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=caac10d6
..0109130806.269529df%40posting.google.com&rnum=2&prev=/groups%3Fq%3Dhttpinpu
tstream%2Bmicrosoft%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dcaa
c10d6.0109130806.269529df%2540posting.google.com%26rnum%3D2
Basically, my goal is as follows... I'm basing my design on this MSDN
sample:
http://msdn.microsoft.com/msdnmag/issues/02/03/WebMethods/default.aspx.
However, rather than rewrite the SOAP stream as this sample does, I wanted a
more scalable solution that could defer the processing of the attachment
portions of the stream until later, letting the WebMethod process almost
immediately. The attachments might be very large, and be streaming in over
a slow link, thus if I use the approach in the sample, I'll be tying up an
ASP.NET thread for an extended interval. Instead, I would ideally read only
enough of the stream to get the initial MIME portion (the SOAP envelope) on
the ASP.NET thread, and spawn a separate thread to read the attachments (of
course, this only helps if the WebMethod doesn't need to report on correct
receipt of the attachments, but many of the apps that would use my
SoapExtension are going to be OK with that caveat).
But experimentation shows that the ChainStream method of my SoapExtension is
not called until the input is completely received. I've contrived a client
test harness to demonstrate this - I split the request in two, and the
ChainStream method will not be called until after the very last byte has
been sent from the client.
This strikes me as a potential performance problem for a large class of
applications, not just my rather esoteric app... Does anyone know of
something I'm missing here to allow me to get the initial portion of the
incoming request immediately?
Attachments protocol.
Here's a Google thread from the MS newsgroups from two years ago that frames
the design issue mentioned in the Subject:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=caac10d6
..0109130806.269529df%40posting.google.com&rnum=2&prev=/groups%3Fq%3Dhttpinpu
tstream%2Bmicrosoft%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dcaa
c10d6.0109130806.269529df%2540posting.google.com%26rnum%3D2
Basically, my goal is as follows... I'm basing my design on this MSDN
sample:
http://msdn.microsoft.com/msdnmag/issues/02/03/WebMethods/default.aspx.
However, rather than rewrite the SOAP stream as this sample does, I wanted a
more scalable solution that could defer the processing of the attachment
portions of the stream until later, letting the WebMethod process almost
immediately. The attachments might be very large, and be streaming in over
a slow link, thus if I use the approach in the sample, I'll be tying up an
ASP.NET thread for an extended interval. Instead, I would ideally read only
enough of the stream to get the initial MIME portion (the SOAP envelope) on
the ASP.NET thread, and spawn a separate thread to read the attachments (of
course, this only helps if the WebMethod doesn't need to report on correct
receipt of the attachments, but many of the apps that would use my
SoapExtension are going to be OK with that caveat).
But experimentation shows that the ChainStream method of my SoapExtension is
not called until the input is completely received. I've contrived a client
test harness to demonstrate this - I split the request in two, and the
ChainStream method will not be called until after the very last byte has
been sent from the client.
This strikes me as a potential performance problem for a large class of
applications, not just my rather esoteric app... Does anyone know of
something I'm missing here to allow me to get the initial portion of the
incoming request immediately?