[
https://issues.apache.org/jira/browse/CXF-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16346472#comment-16346472
]
Peter Keller commented on CXF-7388:
-----------------------------------
Requesting a SOAP response of about 50 MB with JAXB/MTOM results in an
excessive memory heap usage (> 500 MB) which is not acceptable (Camel v2.19.2).
It would be highly appreciated if anyone could fix this.
> Problem with MTOM in Camel-CXF
> ------------------------------
>
> Key: CXF-7388
> URL: https://issues.apache.org/jira/browse/CXF-7388
> Project: CXF
> Issue Type: Bug
> Affects Versions: 3.1.9
> Reporter: Joerg Kessler
> Priority: Major
> Attachments: cxf.client.test.sync.junit.ext.zip
>
>
> Hi,
> I posted this on the CXF user list without getting a response (except from
> Aki who supports this);
> We use CXF 3.1.9 together with Camel 2.17.4. We want to enable MTOM on the
> Camel-CXF producer. To test it I created a simple route using Camel test
> infrastructure where the producer uses a WSDL with base64 encoded payload
> parts. But in the log output of CXF I always get a payload like this
> Http-Method: POST
> Content-Type: multipart/related; type="application/xop+xml";
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6";
> start="<root.mess...@cxf.apache.org>"; start-info="text/xml"
> Headers: {Accept=[*/*],
> breadcrumbId=[ID-WDFN32392889A-65347-1494850621554-0-1],
> Cache-Control=[no-cache], connection=[keep-alive], Content-Length=[487],
> content-type=[multipart/related; type="application/xop+xml";
> boundary="uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6";
> start="<root.mess...@cxf.apache.org>"; start-info="text/xml"],
> Host=[localhost:8770], Pragma=[no-cache], SOAPAction=[""],
> User-Agent=[Apache-CXF/3.1.9]}
> Payload: --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6
> Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
> Content-Transfer-Encoding: binary
> Content-ID: <root.mess...@cxf.apache.org>
> <soap:Envelope
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><typ:testXop
>
> xmlns:typ="http://cxf.apache.org/mime/types";><typ:name>?</typ:name><typ:attachinfo>U1VDQ0VTUw==</typ:attachinfo></typ:testXop></soap:Body></soap:Envelope>
> --uuid:2a84a041-d9ce-4caf-a8e1-b4247e1ad6d6--
> This is not MTOM. The endpoint configuration is
> <cxf:cxfEndpoint id="clientEndpoint"
> address="http://localhost:8770/cxf/mtom"; bus="ClientBus"
> wsdlURL="wsdl/mtom_xop.wsdl">
> <cxf:properties>
> <entry key="dataFormat" value="PAYLOAD" />
> <entry key="defaultOperationName" value="testXop" />
> <entry key="defaultOperationNamespace"
> value="http://cxf.apache.org/mime"/>
> <entry key="mtom-enabled" value="true" />
> </cxf:properties>
> </cxf:cxfEndpoint>
> Here I even used a WSDL that is used in the CXF MTOM tests. Then I compared
> the execution of the relevant interceptors in Camel-CXF and CXF and found one
> difference:
> In AbstractOutDatabindingInterceptor. writeToOutputStream() it is checked
> that the data binding is implemented by the class
> org.apache.cxf.jaxb.JAXBDataBinding. That is correct for CXF but Camel-CXF
> sets in CxfEndpoint the binding to
> org.apache.camel.component.cxf.HybridSourceDataBinding which is derived from
> JAXBDataBinding but of course is a different class. This seems to prevent the
> completion of the MTOM conversion. I changed the code locally so that now all
> subclasses are accepted and now the attachment processing gets really called.
> But now the next problem apears; HybridSourceDataBinding.createWriter()
> raises an exception:
> java.lang.UnsupportedOperationException: The type java.io.OutputStream is not
> supported.
> at
> org.apache.camel.component.cxf.HybridSourceDataBinding.createWriter(HybridSourceDataBinding.java:87)
> I guess the method getSupportedWriterFormats of
> JAXBDataBinding/HybridSourceDataBinding should prevent something like this
> but in this case it does not work.
> I am also unsure whether the problem is now really in CXF or in Camel-CXF.
> Therefore please forward it to Camel if the problem is locarted there.
> Best Regards,
> Jörg
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
