Serializers do currently write to a stream. At issue, I believe, is the fact that Apache SOAP *always* serializes the SOAP envelope into a string, and then serializes that envelope and any attachments into a byte array to send. The latter is done so that an HTTP Content-Length header can be created. The former may just be done for no other reason than that is how the code was originally written.
I have already started contemplating a change to the second step, namely streaming the response with no Content-Length header. This is less of a help on calls with large SOAP envelopes than calls with large attachments (because, as I said, the SOAP envelopes would already be serialized to Strings), but it would help a lot of people who are basically transferring large documents as Strings, byte arrays or DOM Elements, since those documents could be handled as attachments. Unfortunately, folks that must interop with .NET would not benefit from this, since .NET does not support the original SOAP Attachments spec (which they co-authored), choosing to support DIME exclusively instead. So, the handling of large payloads is definitely something we are looking to improve. If you are interested in exploring alternative technologies to alleviate your problems, I highly recommend you consider Axis (http://xml.apache.org/axis/), which may be better than Apache SOAP for your application. Scott Nichol ----- Original Message ----- From: "Paul Marshall" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 14, 2002 8:07 AM Subject: Re: streaming out large xml documents to an rpc-based client > Scott Nichol wrote: > > Paul, > > > > Is the OutOfMemoryException occuring on the server? What is the Java > > data type of the object you are returning? Do you use one of the > > supplied serializers, or a custom one? > > > > Scott Nichol > > > > Hi Scott, > > Thanks for resoponding. > I'me talking about a custom Class that is serialized/deserialized with a > custom serialzier ( both are part of a custom databinding framework ). > The problem of the return object getting too big has currently only > occured on the server. Once the server actually has enough memory to > respond with the large object, the client might well also run into > problems. That's a separate problem however. > > So the idea of writing xml to the servlet response stream would only be > valid to improve serverside efficiency. > Some first ideas would involve having a way of declaring a method to be > "streaming", so that the SOAP Implementation stops to be responsible for > the serialization of the return object but instead passes some open > stream ( perhaps not directly the servlet response stream ) to the > implementing service. The service could then "manually" serialize chunks > of the inteded return object and print these into the stream, in stead > of growing a large object in memory. The soap framework would just > handle the envelop etc. and blend the surrounding envelop xml text with > the streaming body of the method return value into the servlet response > stream. A change to this "streaming" architecture would definitely mean > a lot of work, even if the soap implementation would support it out of > the box, as the implementing classes are currently ejb's that can not so > easily take a stream as input argument... > > On my project however, we are still evaluating other options to deal > with the problem, and so it's not sure yet, that we will try anything of > the likes. > > > I will get in touch with Virender Sandhu ( who seams to have a solution > like this ) as soon as I get more time. > > Cheers > > Paul > > > > > -- > Kostenlose Stundenerfassung mit http://time.jambit.com > ------------------------------------------------------ > Dipl.Phys. Paul Marshall, Software Architect > > jambit Software Development & Management GmbH > Sendlinger Strasse 24, D-80331 Muenchen > http://www.jambit.com > > fon: +49.89.260 19 609 > fax: +49.89.260 19 585 > > PGP Fingerprint: 2A03 9F7A 65AE 33A0 FE49 B8D2 ADA8 0F96 3819 0633 > PGP Keyserver: http://www.dfn-pca.de/pgpkserv > > > -- > To unsubscribe, e-mail: <mailto:soap-user-unsubscribe@;xml.apache.org> > For additional commands, e-mail: <mailto:soap-user-help@;xml.apache.org> > > -- To unsubscribe, e-mail: <mailto:soap-user-unsubscribe@;xml.apache.org> For additional commands, e-mail: <mailto:soap-user-help@;xml.apache.org>
