Return-Path: X-Original-To: apmail-axis-java-dev-archive@www.apache.org Delivered-To: apmail-axis-java-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 44609C728 for ; Sat, 28 Apr 2012 11:18:12 +0000 (UTC) Received: (qmail 21053 invoked by uid 500); 28 Apr 2012 11:18:11 -0000 Delivered-To: apmail-axis-java-dev-archive@axis.apache.org Received: (qmail 20934 invoked by uid 500); 28 Apr 2012 11:18:11 -0000 Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@axis.apache.org Delivered-To: mailing list java-dev@axis.apache.org Received: (qmail 20914 invoked by uid 99); 28 Apr 2012 11:18:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Apr 2012 11:18:11 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Apr 2012 11:18:09 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 0764B425673 for ; Sat, 28 Apr 2012 11:17:49 +0000 (UTC) Date: Sat, 28 Apr 2012 11:17:49 +0000 (UTC) From: "Andreas Veithen (JIRA)" To: java-dev@axis.apache.org Message-ID: <1816482793.6193.1335611869031.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <1018535613.392.1335363499121.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Issue Comment Edited] (AXIS2-5301) Axis2 MTOM client outof memory error when downloading file from service MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/AXIS2-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264282#comment-13264282 ] Andreas Veithen edited comment on AXIS2-5301 at 4/28/12 11:16 AM: ------------------------------------------------------------------ Yes, if SwA and MTOM are both enabled, then SwA takes precedence (because it defines a different message model, and not just an optimization of the SOAP model). This means that MTOM-style attachments will be inlined. Note that the OOM error reveals another issue, namely that Axis2 attempts to read the entire SOAP part into memory before starting to process it. This is described in AXIS2-5302. With a fix for that issue applied, the OOM error would be slightly different: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at com.ctc.wstx.util.TextBuffer.finishCurrentSegment(TextBuffer.java:1146) at com.ctc.wstx.sr.BasicStreamReader.readTextSecondary(BasicStreamReader.java:4749) at com.ctc.wstx.sr.BasicStreamReader.readCoalescedText(BasicStreamReader.java:4113) at com.ctc.wstx.sr.BasicStreamReader.finishToken(BasicStreamReader.java:3688) at com.ctc.wstx.sr.BasicStreamReader.safeFinishToken(BasicStreamReader.java:3644) at com.ctc.wstx.sr.BasicStreamReader.getText(BasicStreamReader.java:851) at org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.getText(XMLStreamReaderWrapper.java:164) at org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.getText(XMLStreamReaderWrapper.java:164) at org.apache.axiom.util.stax.XMLStreamReaderUtils.writeTextTo(XMLStreamReaderUtils.java:287) at org.apache.axiom.om.impl.llom.SwitchingWrapper.writeTextTo(SwitchingWrapper.java:419) at org.apache.axiom.util.stax.XMLStreamReaderUtils.writeTextTo(XMLStreamReaderUtils.java:285) at org.apache.axiom.util.stax.XMLStreamReaderUtils.getDataHandlerFromElement(XMLStreamReaderUtils.java:237) at com.sample.sample.sampleservice.SampleServiceStub$SampleResponseType$Factory.parse(SampleServiceStub.java:749) at com.sample.sample.sampleservice.SampleServiceStub$SampleResponse$Factory.parse(SampleServiceStub.java:2002) at com.sample.sample.sampleservice.SampleServiceStub.fromOM(SampleServiceStub.java:2109) at com.sample.sample.sampleservice.SampleServiceStub.sampleRequest(SampleServiceStub.java:193) at com.sample.sampleservice.client.Client.main(Client.java:45) With that stack trace it is clear that the OOM error occurs while reading base64Binary data from the SOAP part. Interestingly that stack trace also reveals another issue (or better opportunity for improvement), namely AXIOM-417. was (Author: veithen): Yes, if SwA and MTOM are both enabled, then SwA takes precedence (because it defines a different message model, and not just an optimization of the SOAP model). This means that MTOM-style attachments will be inlined. Note that the OOM error reveals another issue, namely that Axis2 attempts to read the entire SOAP part into memory before starting to process it. This is described in AXIS2-5302. With a fix for that issue applied, the OOM error would be slightly different: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at com.ctc.wstx.util.TextBuffer.finishCurrentSegment(TextBuffer.java:1146) at com.ctc.wstx.sr.BasicStreamReader.readTextSecondary(BasicStreamReader.java:4749) at com.ctc.wstx.sr.BasicStreamReader.readCoalescedText(BasicStreamReader.java:4113) at com.ctc.wstx.sr.BasicStreamReader.finishToken(BasicStreamReader.java:3688) at com.ctc.wstx.sr.BasicStreamReader.safeFinishToken(BasicStreamReader.java:3644) at com.ctc.wstx.sr.BasicStreamReader.getText(BasicStreamReader.java:851) at org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.getText(XMLStreamReaderWrapper.java:164) at org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.getText(XMLStreamReaderWrapper.java:164) at org.apache.axiom.util.stax.XMLStreamReaderUtils.writeTextTo(XMLStreamReaderUtils.java:287) at org.apache.axiom.om.impl.llom.SwitchingWrapper.writeTextTo(SwitchingWrapper.java:419) at org.apache.axiom.util.stax.XMLStreamReaderUtils.writeTextTo(XMLStreamReaderUtils.java:285) at org.apache.axiom.util.stax.XMLStreamReaderUtils.getDataHandlerFromElement(XMLStreamReaderUtils.java:237) at com.sample.sample.sampleservice.SampleServiceStub$SampleResponseType$Factory.parse(SampleServiceStub.java:749) at com.sample.sample.sampleservice.SampleServiceStub$SampleResponse$Factory.parse(SampleServiceStub.java:2002) at com.sample.sample.sampleservice.SampleServiceStub.fromOM(SampleServiceStub.java:2109) at com.sample.sample.sampleservice.SampleServiceStub.sampleRequest(SampleServiceStub.java:193) at com.sample.sampleservice.client.Client.main(Client.java:45) With that stack trace it is clear that the OOM error occurs while reading base64Binary data from the SOAP part. > Axis2 MTOM client outof memory error when downloading file from service > ----------------------------------------------------------------------- > > Key: AXIS2-5301 > URL: https://issues.apache.org/jira/browse/AXIS2-5301 > Project: Axis2 > Issue Type: Bug > Components: adb, databinding > Affects Versions: 1.6.1 > Environment: Windows XP , Axis2 1.6.1, JDK 1.5 > Reporter: Sridhar Ratna > Labels: file_download_service, large_file_download, stream_copy_exception, webservice_download_client > Attachments: SampleService.zip, SampleServiceClient.zip > > > I am trying to upload and download large binary files with axis2 using MTOM. I am able to upload upto 2GB file without any memory issue either at server side or client side. But when downloading file from server to client, client is getting out of memory, though the server is sending a stream. > When the response received at client side, javax.activation.Datahandler is embedded in the response which is a pointer to InputStream. Ideallly it should not give out of memory. And this is the same mechanism while uploading, and there is no problem at that end. > Seems to be a bug at client side handling of large documents in response stream. > WSDL is > > > > Please Type your service description here > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > and the service class > public class SampleService implements SampleServiceSkeletonInterface { > public SampleResponse sampleRequest(SampleRequest req) { > try { > SampleResponse response = new SampleResponse(); > SampleResponseType type = new SampleResponseType(); > FileInputStream fis = new FileInputStream("c:/tmp/"+req.getSampleRequest().getFileName()); > DataHandler dh = new DataHandler(new StreamDataSource(fis, req.getSampleRequest().getContentType())); > type.setContent(dh); > type.setFileName(req.getSampleRequest().getFileName()); > response.setSampleResponse(type); > return response; > } catch (FileNotFoundException e) { > e.printStackTrace(); > } > > return null; > } > } > And the client code > public static void main(String[] args) throws Exception{ > SampleServiceStub stub = new SampleServiceStub(); > > stub._getServiceClient().getOptions().setProperty(Constants.Configuration.ENABLE_MTOM, Constants.VALUE_TRUE); > //stub._getServiceClient().getOptions().setProperty(Constants.Configuration.ENABLE_SWA, Constants.VALUE_TRUE); > stub._getServiceClient().getOptions().setTimeOutInMilliSeconds(1000*60*10 ); > > //stub._getServiceClient().getOptions().setProperty(Constants.Configuration.CACHE_ATTACHMENTS, Constants.VALUE_TRUE); > //stub._getServiceClient().getOptions().setProperty(Constants.Configuration.ATTACHMENT_TEMP_DIR, "c:/tmp"); > //stub._getServiceClient().getOptions().setProperty(Constants.Configuration.FILE_SIZE_THRESHOLD, "4000"); > SampleRequestType type = new SampleRequestType(); > type.setFileName("server.log"); > type.setContentType("text/plain"); > SampleRequest request = new SampleRequest(); > request.setSampleRequest(type); > SampleResponse response = stub.sampleRequest(request); > > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org For additional commands, e-mail: java-dev-help@axis.apache.org