Question about MessageContext.setTimeout()
hello all, I would like to know what the meaning of the value behind the getTimeout() and setTimeout() methods in the org.apache.axis.MessageContext class. Is that the number of milliseconds until the context is disposed of? that is, it will stick around in memory on the server until that time has elapsed? It appears that the default value is 60 milliseconds, or 10 minutes. That seems like an awfully long time. I was considering setting the timeout down to 30 seconds, since my web service is handling a lot of concurrent requests. Any thoughts and/or advice? thanks! cheers, - Jared
Re: OutOfMemoryError when submitting large SOAP requests to Axis
hi Linus, thanks for the link! after doing some reading, I'm still not sure which category this service falls under. I've attached an edited (identifying info replaced by '' and '') version of the WSDL for this service. For reference, I have -Xmx1024m set in the JVM. Have you had any luck with the attachment streaming? I can't figure out how to enable or configure Axis to use it. This is my first time working with Axis, so needless to say I'm fumbling in the dark a little bit. This codebase is larger than any I've worked in the past for a web service, as well. I'm going to continue to investigate and research - I'll post what I find, and hope you'll keep me posted to your progress. cheers, - Jared On 2/2/06, Linus Kamb [EMAIL PROTECTED] wrote: 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 filenamespacer.gif/filename mimedataR0lGODlhAQABAIAAACH5BAEALAABAAEAAAICRAEAOw==/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://.yyy.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
OutOfMemoryError when submitting large SOAP requests to Axis
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 filenamespacer.gif/filename mimedataR0lGODlhAQABAIAAACH5BAEALAABAAEAAAICRAEAOw==/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://.yyy.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
Re: OutOfMemoryError when submitting large SOAP requests to Axis
Of course, the moment I send off a message to a mailing list, after having claimed I read the archives, I find a message that nearly answers my question. http://marc.theaimsgroup.com/?l=axis-userm=113871304213627w=2 This message mentions this JIRA issue: http://issues.apache.org/jira/browse/AXIS-2221 which looks like it will solve my problem, however, I'm not sure how to go about implementing it. Is there a configuration option to Axis to use the streaming capability? What changes, if any, should I make to my application code? cheers, - Jared On 2/2/06, Jared Klett [EMAIL PROTECTED] 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 filenamespacer.gif/filename mimedataR0lGODlhAQABAIAAACH5BAEALAABAAEAAAICRAEAOw==/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://.yyy.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
Re: OutOfMemoryError when submitting large SOAP requests to Axis
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 filenamespacer.gif/filename mimedataR0lGODlhAQABAIAAACH5BAEALAABAAEAAAICRAEAOw==/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://.yyy.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
Re: Status w/r/t memory leaks...
greetings all, That's funny, I was just working on composing a long message describing the memory issue I'm having with Axis+Tomcat that I haven't been able to solve by tweaking JVM memory or GC parameters or by upgrading to Axis 1.3. So Dims, you're saying to do a checkout of the latest CVS according to this page: http://ws.apache.org/axis/cvs.html and do our own build, which will give us 1.3 + the 3 fixes detailed in JIRA? just want to confirm... thanks! cheers, - Jared On 2/1/06, Davanum Srinivas [EMAIL PROTECTED] wrote: All 3 are fixed in latest SVN. thanks, dims On 2/1/06, Jesse Sightler [EMAIL PROTECTED] wrote: I've seen several issues in JIRA relating to memory leaks on the server-side of Axis recently. Specifically, I've noticed: http://issues.apache.org/jira/browse/AXIS-2278 https://issues.apache.org/jira/browse/AXIS-2266 https://issues.apache.org/jira/browse/AXIS-2185 What are peoples current experiences with memory leaks in Axis1? Is the CVS version significantly more stable than the current release version? Is a 1.4 release forthcoming to resolve the issues? Thanks, Jess -- Davanum Srinivas : http://wso2.com/blogs/
Re: Status w/r/t memory leaks...
hi Dims, ok, the SVN checkout is proceeding - I'm looking in the branches/ subdir - should I build AXIS_1_4_FINAL to get those 3 fixes, or should I be in the trunk, or something else? thanks! cheers, - Jared On 2/1/06, Davanum Srinivas [EMAIL PROTECTED] wrote: svn co http://svn.apache.org/repos/asf/webservices/axis/ axis -- dims On 2/1/06, Jared Klett [EMAIL PROTECTED] wrote: greetings all, That's funny, I was just working on composing a long message describing the memory issue I'm having with Axis+Tomcat that I haven't been able to solve by tweaking JVM memory or GC parameters or by upgrading to Axis 1.3. So Dims, you're saying to do a checkout of the latest CVS according to this page: http://ws.apache.org/axis/cvs.html and do our own build, which will give us 1.3 + the 3 fixes detailed in JIRA? just want to confirm... thanks! cheers, - Jared On 2/1/06, Davanum Srinivas [EMAIL PROTECTED] wrote: All 3 are fixed in latest SVN. thanks, dims On 2/1/06, Jesse Sightler [EMAIL PROTECTED] wrote: I've seen several issues in JIRA relating to memory leaks on the server-side of Axis recently. Specifically, I've noticed: http://issues.apache.org/jira/browse/AXIS-2278 https://issues.apache.org/jira/browse/AXIS-2266 https://issues.apache.org/jira/browse/AXIS-2185 What are peoples current experiences with memory leaks in Axis1? Is the CVS version significantly more stable than the current release version? Is a 1.4 release forthcoming to resolve the issues? Thanks, Jess -- Davanum Srinivas : http://wso2.com/blogs/ -- Davanum Srinivas : http://wso2.com/blogs/
