axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Ewins <Brian.Ew...@btinternet.com>
Subject Re: Axis client, OutOfMemoryException
Date Tue, 14 Jan 2003 15:51:48 GMT


Brian W. Young wrote:
> I just recalled that Strings in a SOAP request are sent as element text 
> and not embedded in a  CDATA section.  Since my String is actually an 
> XML document, this means i've got around 50,000 tags with < and > that 
> are all being escaped into entities.  My guess is that this is too much 
> work for the XML parser on the client side- processing the element text 
> may be what is causing the OutOfMemoryException. 
> Why are SOAP parameters not embedded inside CDATA sections?  Is there 
> some way to force this to happen?

AFAIK, no. There is no way to specify the use of CDATA in XML schema, 
hence its not in WSDL, hence it doesnt make it into SOAP toolkits.

However - what you've described is a bad way to achieve what you are 
trying to do. There are a number of issues -
- by embedding a large document as a string, you prevent SAX-style 
processing and force the entire document to be loaded into memory. You 
can transfer the document as XML and avoid the second parsing stage - 
this is document/literal encoding (aka doc-lit). There are dozens of 
threads in this mailing list on this approach. See, eg 
http://www-106.ibm.com/developerworks/library/ws-docstyle.html?n-ws-6202

- ignoring for a moment that your file is XML, you can use soap with 
attachments (SwA) to send it. Again there are lots of threads in this 
list about this approach. See eg
http://www.acknowledge.co.uk/snippets/java/code_examples/webservices/simplesoapattachmentsclient.html

- XML documents are not really character (string) data in the first 
place. They are binary, and can only be correctly interpreted as 
character data after reading the encoding (see 
http://www.w3.org/TR/REC-xml#sec-guessing), though you won't see this 
problem much in the common western encodings. This points to another way 
to shift your data - gzip and base64 encode it. This should reduce the 
size somewhat (usually, 1/5 of the size from gzip, 1.5 times that from 
base 64) and will avoid /any/ entity expansion. Java has 
GZIPInput/Output streams that can help with this,  base 64 utils are 
easy to find. I'd only recommend this approach if interop issues prevent 
you following the herd doing SwA or doc-lit.

Hope this helps,
Baz




Mime
View raw message