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>

Reply via email to