Fuse / CXF: Jax-Ws client operation gives SocketTimeoutException
vikingsteve Jul 3, 2013 7:04 AMI'm moving a legacy application, MyService, into JBoss Fuse (running in fuse fabric).
MyService uses JaxWS to invoke operations on another web service. I am generating the web service classes from a wsdl file, the same wsdl as in the legacy application.
The web service client is configured from an wsdl file to talk to an external service at https://another.company/anotherService.svc. I know that this service is up and running ok since the legacy application (based on the same wsdl) can talk to it.
However in my new service JBoss Fuse Fabric, when the web service client is invoked,the first two operations succeed whilst the third one fails.
operationTest - OK
operationTwo(String a, String b) - OK
operationThree(String a, String b, String c, String d, String e, String f, MySubmitTask submitTask) - FAILS
Stack trace:
javax.xml.ws.WebServiceException: Could not send Message.
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145)
...
Caused by: java.net.SocketTimeoutException: SocketTimeoutException invoking https://another.system/AnotherWebService.svc: Read timed out
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)[:1.7.0_25]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_25]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_25]
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_25]
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1467)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1452)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:660)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:530)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134)
The failure occurs after 60 seconds. Typically, in the legacy application, the response is around 1 second.
I have set global http proxy settings which I know are correct since the legacy application runs successfully from the same machine using the same http proxy settings.
The problem seems to be the content of the last parameter on the web service operation.
operationThree(String a, String b, String c, String d, String e, String f, MySubmitTask submitTask) - FAILS
The MySubmitTask class is generated from an xsd file (the same xsd file as the legacy application). Somewhere down within it's data structure, it contains a String containing xml data, which is 4kb. If I set this string to null, then the web operation succeeds.
I have run a debugger into the invocation of operationThree and compared the legacy application to the new service running in JBoss Fuse.
- legacy application uses com.sun.xml.ws.client.sei.SEIStub
- jboss fuse service uses org.apache.cxf.jaxws.JasWsClientProxy
In other words, as far as I can see, really the only difference is that the legacy application used sun / glassfish web service client and the JBoss Fuse service uses apache cxf.
The version of apache cxf seems to be: org.apache.cxf:cxf-rt-frontend-jaxws:2.6.0.redhat-60024.
Can anybody please help?
Or are there any known issues with:
- apache cxf?
- jaxws in jboss fuse fabric?
- sitting behind an http proxy?
- string data of 4kb?
- jaxws client talking over https to http basic web service?
Thanks very much in advance, we really struggling with this problem