You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "yogesh_d1@yahoo.com" <yo...@yahoo.com> on 2014/01/08 15:00:55 UTC
WSDL first MTOM enabled cxf 2.7 web-service client causes Java heap
space error for large attachments
I am trying to build a WSDL-first java web-service using CXF2.7.7 using MTOM.
My intention is to be able to upload large (multi GB) files through this
web-serviceBelow is a fragment of my the WSDL
My intention is to use MTOM ( as it would be evident from the element
type="xs:base64Binary" xmime:expectedContentTypes="application/octet-stream)
for uploading objects through this service.I have also configured my jax WS
end-point to use MTOM as seen from my Server side Spring configuration file
fragment below And
similarly I have also configured my jax-ws client to use MTOM as seen from
my client side spring configuration file below
And I am also including a relevant fragment of my Java code for client below
/* --- Web-service client
***************************************************************************
*/ package com.example.objectstoreservice.client; import
java.util.List; import java.awt.Image; import
java.io.ByteArrayInputStream; import java.io.File; import
java.io.InputStream; import java.io.File; import
java.io.FileInputStream; import java.io.IOException; import
javax.activation.DataHandler; import javax.activation.FileDataSource;
import javax.xml.namespace.QName; import
com.example.objectstoreservice.ObjectStoreService; import
com.example.objectstoreservice.ObjectReqParam; import
com.example.objectstoreservice.ObjectRespParam; public final class
ObjectStoreServiceTester { ObjectStoreService objectStoreService;
public ObjectStoreService getObjectStoreService() { return
objectStoreService; } public void
setObjectStoreService(ObjectStoreService objectStoreService) {
this.objectStoreService = objectStoreService; } public void
testObjectStoreService() { System.out.println("Now uploading a data
file to service"); ObjectReqParam objReqParam = new ObjectReqParam() ;
objReqParam.setObjName("File"); String
fileName="C:/root/opt/files/ToSend.jpg"; FileDataSource
inFileDataSource=new FileDataSource(fileName); DataHandler dataHandler =
new DataHandler(inFileDataSource); System.out.println("Check content-type
from dataHandler : " + dataHandler.getContentType());
System.out.println("Check obj signature from dataSource : " +
dataHandler.getDataSource()); System.out.println("Check file-name from
dataSource : " + dataHandler.getDataSource().getName());
objReqParam.setObjData(dataHandler); System.out.println("Now uploading
file:" + fileName); objectStoreService.uploadObject(objReqParam);
System.out.println("Object upload successful"); } }When run - this
client runs fine for small attachments, but gives following error for large
attachments ( based on my JVM heap space allocated) ** An exception
occured while executing the Java class. null: InvocationTargetException:
Java heap space ** Below is the full stack trace. **Please let me know if
you see something amiss or if I should be doing something different ***- And
BTW I have seen some other posts with similar problems and am wondering if
anyone has done MTOM for large files.Is there a way I can explicitly force
it to stream the file or force it to send in small chunks ? * MTOM: An
exception occured while executing the Java class. null at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:217) at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:153) at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:145) at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje
ct(LifecycleModuleBuilder.java:84) at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje
ct(LifecycleModuleBuilder.java:59) at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu
ild(LifecycleStarter.java:183) at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl
eStarter.java:161) at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at
org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at
org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at
org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:57) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun
cher.java:290) at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav
a:230) at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La
uncher.java:409) at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:
352) Caused by: org.apache.maven.plugin.MojoExecutionException: An
exception occured while executing the Java class. null at
org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:346) at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default
BuildPluginManager.java:101) at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
.java:209) ... 19 more Caused by:
java.lang.reflect.InvocationTargetException at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:57) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:291)
at java.lang.Thread.run(Thread.java:744) Caused by:
java.lang.OutOfMemoryError: Java heap space at
com.sun.xml.bind.v2.util.ByteArrayOutputStreamEx.readFrom(ByteArrayOu
tputStreamEx.java:75) at
com.sun.xml.bind.v2.runtime.unmarshaller.Base64Data.get(Base64Data.ja
va:196) at
com.sun.xml.bind.v2.runtime.unmarshaller.Base64Data.writeTo(Base64Dat
a.java:312) at
com.sun.xml.bind.v2.runtime.output.UTF8XmlOutput.text(UTF8XmlOutput.j
ava:312) at
com.sun.xml.bind.v2.runtime.XMLSerializer.leafElement(XMLSerializer.j
ava:356) at
com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl$PcdataImpl.
writeLeafElement(RuntimeBuiltinLeafInfoImpl.java:183) at
com.sun.xml.bind.v2.runtime.MimeTypedTransducer.writeLeafElement(Mime
TypedTransducer.java:96) at
com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTrans
ducedAccessorImpl.writeLeafElement(TransducedAccessor.java:256) at
com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.serial
izeBody(SingleElementLeafProperty.java:130) at
com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBean
InfoImpl.java:361) at
com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerialize
r.java:696) at
com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serial
izeBody(SingleElementNodeProperty.java:158) at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Eleme
ntBeanInfoImpl.java:161) at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Eleme
ntBeanInfoImpl.java:131) at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(Element
BeanInfoImpl.java:333) at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(Element
BeanInfoImpl.java:340) at
com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(Element
BeanInfoImpl.java:76) at
com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.j
ava:494) at
com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:
323) at
com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.jav
a:251) at
javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshal
lerImpl.java:95) at
org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder
.java:612) at
org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.ja
va:240) at
org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:169)
at org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writePar
ts(AbstractOutDatabindingInterceptor.java:114) at
org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutIn
terceptor.java:68) at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
orChain.java:272) at
org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565) at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474) at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377) at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330) at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)And
another peculiar thing If I check the SOAP message I still see the
attachment going "inline" as base64 encoded and not as a separate part ...
at-least the CXF logging shows that to me. This is regardless of the size of
attachment I try to send
--
View this message in context: http://cxf.547215.n5.nabble.com/WSDL-first-MTOM-enabled-cxf-2-7-web-service-client-causes-Java-heap-space-error-for-large-attachments-tp5738387.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: WSDL first MTOM enabled cxf 2.7 web-service client causes Java
heap space error for large attachments
Posted by "yogesh_d1@yahoo.com" <yo...@yahoo.com>.
This problems was solved - thanks to inputs from Dan
see
http://cxf.547215.n5.nabble.com/MTOM-OutOfMemory-td547525i20.html#a5738407
--
View this message in context: http://cxf.547215.n5.nabble.com/WSDL-first-MTOM-enabled-cxf-2-7-web-service-client-causes-Java-heap-space-error-for-large-attachments-tp5738387p5738697.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: WSDL first MTOM enabled cxf 2.7 web-service client causes Java
heap space error for large attachments
Posted by "yogesh_d1@yahoo.com" <yo...@yahoo.com>.
Hi Andrei,
Sure the service side does read attachments from the stream.
With smaller attachment this code works fine.
In response to another post - I got following input from Dan - reproducing
it here ( Dan I hope you don't mind )
Daniel Kulp
Jan 9 at 9:28 PM
To
users@cxf.apache.org
yogesh_d1@yahoo.com
On Jan 9, 2014, at 1:11 AM, yogesh_d1@yahoo.com wrote:
> List -I am facing a similar problem and have made a post for this. Looking
> at
> this I would like to know if any of the users here were able to establish
> working MTOM with large attachments. I would hugely appreciate a working
> sample
You could try modifying the mtom sample in the CXF kits to use a larger
attachment. The samples is fairly small since it’s going in the kit, but
feel free to play with it and see if you can reproduce your issue.
- And I am able to reproduce the same issue with the samples as well that
do MTOM perfectly well
--
View this message in context: http://cxf.547215.n5.nabble.com/WSDL-first-MTOM-enabled-cxf-2-7-web-service-client-causes-Java-heap-space-error-for-large-attachments-tp5738387p5738431.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: WSDL first MTOM enabled cxf 2.7 web-service client causes Java
heap space error for large attachments
Posted by Andrei Shakirin <as...@talend.com>.
Hi,
I see "java.lang.OutOfMemoryError: Java heap space" error stack trace.
Could you check that attachments are really read from the stream on the service side and try to increase JVM heap size?
Regards,
Andrei.
> -----Original Message-----
> From: yogesh_d1@yahoo.com [mailto:yogesh_d1@yahoo.com]
> Sent: Mittwoch, 8. Januar 2014 15:01
> To: users@cxf.apache.org
> Subject: WSDL first MTOM enabled cxf 2.7 web-service client causes Java
> heap space error for large attachments
>
> I am trying to build a WSDL-first java web-service using CXF2.7.7 using
> MTOM.
> My intention is to be able to upload large (multi GB) files through this
> web-serviceBelow is a fragment of my the WSDL
>
>
>
>
>
>
>
>
>
>
>
>
>
> My intention is to use MTOM ( as it would be evident from the element
> type="xs:base64Binary" xmime:expectedContentTypes="application/octet-
> stream)
> for uploading objects through this service.I have also configured my jax WS
> end-point to use MTOM as seen from my Server side Spring configuration file
> fragment below
> And
> similarly I have also configured my jax-ws client to use MTOM as seen from
> my client side spring configuration file below
>
>
> And I am also including a relevant fragment of my Java code for client below
> /* --- Web-service client
> **********************************************************
> *****************
> */ package com.example.objectstoreservice.client; import
> java.util.List; import java.awt.Image; import
> java.io.ByteArrayInputStream; import java.io.File; import
> java.io.InputStream; import java.io.File; import
> java.io.FileInputStream; import java.io.IOException; import
> javax.activation.DataHandler; import javax.activation.FileDataSource;
> import javax.xml.namespace.QName; import
> com.example.objectstoreservice.ObjectStoreService; import
> com.example.objectstoreservice.ObjectReqParam; import
> com.example.objectstoreservice.ObjectRespParam; public final class
> ObjectStoreServiceTester { ObjectStoreService objectStoreService;
> public ObjectStoreService getObjectStoreService() { return
> objectStoreService; } public void
> setObjectStoreService(ObjectStoreService objectStoreService) {
> this.objectStoreService = objectStoreService; } public void
> testObjectStoreService() { System.out.println("Now uploading a
> data
> file to service"); ObjectReqParam
> objReqParam = new ObjectReqParam() ;
> objReqParam.setObjName("File"); String
> fileName="C:/root/opt/files/ToSend.jpg"; FileDataSource
> inFileDataSource=new FileDataSource(fileName); DataHandler
> dataHandler =
> new DataHandler(inFileDataSource); System.out.println("Check
> content-type
> from dataHandler : " + dataHandler.getContentType());
> System.out.println("Check obj signature from dataSource : " +
> dataHandler.getDataSource()); System.out.println("Check file-name
> from
> dataSource : " + dataHandler.getDataSource().getName());
>
> objReqParam.setObjData(dataHandler);
> System.out.println("Now uploading
> file:" + fileName);
> objectStoreService.uploadObject(objReqParam);
> System.out.println("Object upload successful");
> } }When run - this
> client runs fine for small attachments, but gives following error for large
> attachments ( based on my JVM heap space allocated) ** An exception
> occured while executing the Java class. null: InvocationTargetException:
> Java heap space ** Below is the full stack trace. **Please let me know if you
> see something amiss or if I should be doing something different ***- And
> BTW I have seen some other posts with similar problems and am wondering
> if
> anyone has done MTOM for large files.Is there a way I can explicitly force
> it to stream the file or force it to send in small chunks ? * MTOM: An
> exception occured while executing the Java class. null at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
> .java:217) at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
> .java:153) at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
> .java:145) at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje
> ct(LifecycleModuleBuilder.java:84) at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProje
> ct(LifecycleModuleBuilder.java:59) at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBu
> ild(LifecycleStarter.java:183) at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(Lifecycl
> eStarter.java:161) at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at
> org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:57) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Laun
> cher.java:290) at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.jav
> a:230) at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(La
> uncher.java:409) at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:
> 352) Caused by: org.apache.maven.plugin.MojoExecutionException: An
> exception occured while executing the Java class. null at
> org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:346)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Default
> BuildPluginManager.java:101) at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor
> .java:209) ... 19 more Caused by:
> java.lang.reflect.InvocationTargetException at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:57) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:291)
> at java.lang.Thread.run(Thread.java:744) Caused by:
> java.lang.OutOfMemoryError: Java heap space at
> com.sun.xml.bind.v2.util.ByteArrayOutputStreamEx.readFrom(ByteArrayOu
> tputStreamEx.java:75) at
> com.sun.xml.bind.v2.runtime.unmarshaller.Base64Data.get(Base64Data.ja
> va:196) at
> com.sun.xml.bind.v2.runtime.unmarshaller.Base64Data.writeTo(Base64Dat
> a.java:312) at
> com.sun.xml.bind.v2.runtime.output.UTF8XmlOutput.text(UTF8XmlOutput.j
> ava:312) at
> com.sun.xml.bind.v2.runtime.XMLSerializer.leafElement(XMLSerializer.j
> ava:356) at
> com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl$PcdataImpl.
> writeLeafElement(RuntimeBuiltinLeafInfoImpl.java:183) at
> com.sun.xml.bind.v2.runtime.MimeTypedTransducer.writeLeafElement(Mi
> me
> TypedTransducer.java:96) at
> com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTrans
> ducedAccessorImpl.writeLeafElement(TransducedAccessor.java:256) at
> com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.serial
> izeBody(SingleElementLeafProperty.java:130) at
> com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBean
> InfoImpl.java:361) at
> com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerialize
> r.java:696) at
> com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serial
> izeBody(SingleElementNodeProperty.java:158) at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Eleme
> ntBeanInfoImpl.java:161) at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(Eleme
> ntBeanInfoImpl.java:131) at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(Element
> BeanInfoImpl.java:333) at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(Element
> BeanInfoImpl.java:340) at
> com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(Element
> BeanInfoImpl.java:76) at
> com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.j
> ava:494) at
> com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:
> 323) at
> com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.jav
> a:251) at
> javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshal
> lerImpl.java:95) at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder
> .java:612) at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.ja
> va:240) at
> org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:169)
> at org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writePar
> ts(AbstractOutDatabindingInterceptor.java:114) at
> org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutIn
> terceptor.java:68) at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
> orChain.java:272) at
> org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565) at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474) at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377) at
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330) at
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)And
> another peculiar thing If I check the SOAP message I still see the attachment
> going "inline" as base64 encoded and not as a separate part ...
> at-least the CXF logging shows that to me. This is regardless of the size of
> attachment I try to send
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/WSDL-first-
> MTOM-enabled-cxf-2-7-web-service-client-causes-Java-heap-space-error-
> for-large-attachments-tp5738387.html
> Sent from the cxf-user mailing list archive at Nabble.com.