Hi, Jared.
doc/lit wrapped is the web service "style". There are various styles:
primarily RPC-encoded, document/literal, and "wrapped" which is a
variation on document/literal. Much information available about that.
The following is probably not the best introductory information, but I
happened to see it this morning:
http://www-128.ibm.com/developerworks/webservices/library/ws-whichwsdl/
I guess I was just wondering if your web service was trying to parse
the SOAP msg XML into a DOM Element.
I haven't tried mulitple simultaneous submits. I suppose my service
might run out of memory too.
I have my java startup params set to -Xmx768m, and I currently reject
messages over 2MB (rather than trying to parse the XML.)
I suppose this isn't going to help your situation. I'm going to look
into the attachment streaming that Dims mentioned for my app.
Linus
Jared Klett wrote:
hi Linus,
I can send a single request at a time of the required size, and it
will succeed. However, when I start more simultaneous requests beyond
the first one, they invariably fail with OutOfMemoryErrors. The OOM
occurs somewhere inside of Axis.
The web service works like this: it runs inside Tomcat, and passes
through a couple of Tomcat filters before reaching the AxisServlet.
I've monitored the logging, and all simultaneous requests make it
through the filters with no problem. Once the flow passes into the
AxisServlet, and subsequently to SOAPMonitor, the OOM's start to
occur.
I attached a debug log snippet to the initial message in this thread.
Also, what do you mean by "doc/lit wrapped"?
cheers,
- Jared
On 2/2/06, Linus Kamb <[EMAIL PROTECTED]> wrote:
What "style" of web service are you using?
I have successfully sent attachments of > 200MB using doc/lit wrapped,
and I'm sure I could send larger ones.
The trouble I run into is when I try to parse the attachments (they are
XML,) but that is outside of Axis/SOAP.
Jared Klett wrote:
greetings all,
I've taken a contract job to improve the performance of a Java Web
Service based on Axis. The service is required to handle multiple
simultaneous SOAP requests that can be anywhere from two to 100 MB in
size. So far, the service fails with an OutOfMemoryError when I submit
any more than one simultaneous request at a time.
I participated in a previous thread entitled "Status w/r/t memory
leaks..." started by Jesse Sightler. I've tried the Axis 1.3 final
release, as well as a version built from the trunk of the latest (as
of yesterday) SVN source tree.
The SOAP requests have a number of attachments in the form of
base64-encoded data, which look something like this:
<data sid="data_5">
<filename>spacer.gif</filename>
<mimedata>R0lGODlhAQABAIAAAAAAAAAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==</mimedata>
</data>
The content inside the <mimedata> tag can be extremely large - as I
mentioned, these requests can be upwards of 100 MB in size.
I've tweaked the JVM parameters, setting the max and initial heap
sizes, the perm gen heap size, as well as trying several different
options to change the behavior of the garbage collector - all to no
avail.
I've narrowed down the problem down to the point where I'm sure it's
happening somewhere inside of Axis - the request is submitted to
AxisServlet, then passed to SOAPMonitor via an invoke() call.
Here is a snippet of the debug log output before the OOM happens:
[] [2006-01-30 15:45:23,404] SAXOutputter - SAXOutputter.endElement
['' reporterCcc]
[] [2006-01-30 15:45:23,404] ProjectResourceBundle -
org.apache.axis.i18n.resource::handleGetObject(endElem00)
[] [2006-01-30 15:45:23,404] SerializationContext - End element reporterCcc
[] [2006-01-30 15:45:23,404] NSStack - NSPop (32)
[] [2006-01-30 15:45:23,404] SAXOutputter - SAXOutputter.endElement
['http://xxxxxxxx.yyyyyyy.com' fileTestSubmission]
[] [2006-01-30 15:45:23,404] ProjectResourceBundle -
org.apache.axis.i18n.resource::handleGetObject(endElem00)
[] [2006-01-30 15:45:23,404] SerializationContext - End element
q1:fileTestSubmission
[] [2006-01-30 15:45:23,404] NSStack - NSPop (32)
[] [2006-01-30 15:45:23,404] SAXOutputter - SAXOutputter.endElement
['http://schemas.xmlsoap.org/soap/envelope/' Body]
[] [2006-01-30 15:45:23,404] ProjectResourceBundle -
org.apache.axis.i18n.resource::handleGetObject(endElem00)
[] [2006-01-30 15:45:23,404] SerializationContext - End element soap:Body
[] [2006-01-30 15:45:23,404] NSStack - NSPop (32)
[] [2006-01-30 15:45:23,404] SAXOutputter - SAXOutputter.endElement
['http://schemas.xmlsoap.org/soap/envelope/' Envelope]
[] [2006-01-30 15:45:23,404] ProjectResourceBundle -
org.apache.axis.i18n.resource::handleGetObject(endElem00)
[] [2006-01-30 15:45:23,404] SerializationContext - End element soap:Envelope
[] [2006-01-30 15:45:23,404] ProjectResourceBundle -
org.apache.axis.i18n.resource::handleGetObject(empty00)
[] [2006-01-30 15:45:23,405] NSStack - NSPop (empty)
[] [2006-01-30 15:45:23,405] SAXOutputter - SAXOutputter.endDocument
[] [2006-01-30 15:45:38,782] ProjectResourceBundle -
org.apache.axis.i18n.resource::handleGetObject(exception00)
[] [2006-01-30 15:45:38,782] EXCEPTIONS - Exception:
java.lang.OutOfMemoryError: Java heap space
I have been looking at the source code to Axis, and I note that in
SOAPPart, around line 444, data is loaded via an InputStream into a
memory-resident byte array. So far that's the only place I can find
that might actually be causing the problem.
It seems logical that a large SOAP request that is separated into
attachments should be written to disk, and then parsed inside of a
buffer. Here is a link to an article with such a code example (under
"Receive and process a SOAP message with SAAJ", a little more than
halfway down the page):
http://www.javaworld.com/javaworld/jw-09-2003/jw-0912-webservices-p2.html
I've read the archives of this mailing list, so I know I'm not the
first one to run into this issue. So far, I have not found any
proposed solutions.
I'm going to continue to investigate, but I would really appreciate
some help or insights from the list. Thanks very much!
cheers,
- Jared
|
