[mule-user] Socket Write Exception on CXF outbound client endpoint with large session

1 view
Skip to first unread message

Peter Sparago

unread,
Jun 16, 2011, 2:50:30 PM6/16/11
to us...@mule.codehaus.org
Here's what I'm trying to do ...

I am calling a Web service from a Mule flow using a dynamically generated outbound CXF client. If the Web service returns a particular SOAP Fault, I want to queue the payload of the message to a JMS queue so I can later retry the Web service call (i.e. an implementation of guaranteed delivery).

Here's how I'm trying to do it ...
I have a component that runs just before the Web service call that stores the payload of a message in the Mule session. I have a component that runs after the Web service call that interrogates the SOAP result and, if it finds the particular SOAP Fault, retrieves the saved message from the Mule session and returns it as the result of the Component onCall handler. There is a choice router that runs after the component that conditionally writes the saved payload to a JMS queue.

Here's the relevant bits of the flow:
<flow name="x">
...
<component><spring-object bean="requestCachingComponent"></spring-object></component>

<cxf:jaxws-client serviceClass="com.tangoe.services.synergyservice.ISynergyService" operation="invoke" /> -->
<outbound-endpoint address="http://#[header:OUTBOUND:serviceDestination]" exchange-pattern="request-response" />

<component><spring-object bean="serviceResultComponent"></spring-object></component>

<choice> <!-- by the way this choice router doesn't work, but one thing at a time -->
<when evaluator="header" expression="OUTBOUND:queueForRetry = true">
<jms:outbound-endpoint queue="queue/service-retries" />
...
</flow>

Here's the problem ...
Whenever I store the request object used to call the Web service in the Mule session, I get a socket write error exception. If I don't store the request in the Mule session this code works as expected. I've noticed that it seems to happen when the session gets "large". That is to say I tried storing a small bit of XML (4K) in the session and the CXF Web service call works (no Socket Write error), however when I store a larger bit of XML (9K) in the header I get the same socket write exception. (Note that the actual request object sent to the Web service is not XML, it's a Java object. I just tried the XML to determine if it had something to do with marshaling my Java Object).

Note: By tracing into the Mule source code, I found that session properties with the prefix of 'MULE' do not get sent to CXF for inclusion in the HTTP header, so I prefixed my session key with 'MULE' and, in fact, the property does not get sent to CXF. This had absolutely no effect which is why I'm pretty sure it has something to do with the size of the base64-encoded session (which I'm guessing is sent in the HTTP request, but I've not verified this).

The exception is ATTACHED to minimize the size of this post. I am using the Mule-3.1.1 community distribution.

I'm pretty desperate. I have a code freeze deadline in less than 2 weeks and I'm running out of time! Please help.

All the Best,
peter

MuleCXFSocketWriteException.txt

David Eason

unread,
Jun 30, 2011, 6:15:28 PM6/30/11
to us...@mule.codehaus.org
Peter,

Have you tried using the enableMuleSoapHeaders="false"

[CXF Module Configuration Reference (MULE 3 User documentation)|http://www.mulesoft.org/documentation/display/MULE3USER/CXF+Module+Configuration+Reference]

Something like this:


<https:outbound-endpoint address="http://#[header:OUTBOUND:serviceDestination]" exchange-pattern="request-response" >
<cxf:jaxws-client serviceClass="com.some.company.IXYZService" operation="invoke" enableMuleSoapHeaders="false"/>
</https:outbound-endpoint>

Regards,

Dave

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email


David Eason

unread,
Jul 7, 2011, 1:38:18 AM7/7/11
to us...@mule.codehaus.org
Peter,

I've set up a test case similar to what you are trying to do and am seeing the same issue myself. For small SESSION variables this works fine but once the SESSION variable grows over a particular size the following exception is thrown (see below)

I'm looking into the root cause of this issue further on this end. In the meantime however, have you thought about persisting the incoming message to either a DB or JMS queue and then just storing the reference to that location in SESSION to reduce the size of what's being cached.

There will obviously be a performance impact of persisting every message BUT the trade off will be greater reliability and a simplified error handling/re-try processing. Anyway just a thought might be a suitable work-around in the interim.

Regards,

Dave

********************************************************************************
Message : null (java.lang.reflect.InvocationTargetException)
Type : org.mule.api.DefaultMuleException
Code : MULE_ERROR-10999
JavaDoc : http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/DefaultMuleException.html
********************************************************************************
Exception stack is:
1. Broken pipe (java.net.SocketException)
java.net.SocketOutputStream:-2 (null)
2. Broken pipe (com.ctc.wstx.exc.WstxIOException)
com.ctc.wstx.sw.BaseStreamWriter:1431 (null)
3. Error writing to XMLStreamWriter. (javax.xml.ws.soap.SOAPFaultException)
org.apache.cxf.jaxws.JaxWsClientProxy:146 (http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/xml/ws/soap/SOAPFaultException.html)
4. null (java.lang.reflect.InvocationTargetException) (org.mule.api.DefaultMuleException)
org.mule.module.cxf.CxfOutboundMessageProcessor:141 (http://www.mulesoft.org/docs/site/current3/apidocs/org/mule/api/DefaultMuleException.html)
********************************************************************************
Root Exception stack trace:
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)....

Peter Sparago

unread,
Jul 7, 2011, 1:34:15 PM7/7/11
to us...@mule.codehaus.org
FYI - The above workaround did not solve the problem.

David Eason

unread,
Jul 12, 2011, 5:30:26 PM7/12/11
to us...@mule.codehaus.org
Peter,

I've been testing this with the Dev team today. Basically they are now seeing the same issue that I can see.

I've raised the following issue in JIRA to track this issue;

[http://www.mulesoft.org/jira/browse/MULE-5641|http://www.mulesoft.org/jira/browse/MULE-5641]

This will be the best place to track this issue moving forward. I'm still looking into this to determine if their is a 'configuration' parameter associated with CXF/http that could be used to configure this size limit, if I find anything I'll let you know.

Regards,

Dave

David Eason

unread,
Jul 14, 2011, 3:01:27 PM7/14/11
to us...@mule.codehaus.org
Peter,

I don't know if you're tracking the JIRA associated with this but basically here's the source of the issue that I'm seeing on my side, probably similar to what you are seeing.

===========
When using http endpoints Mule session is stored as a custom http header so there are some limitations in header size. HTTP specification does not limit length of headers at all. However web-servers do limit header size they accept, throwing “413 Entity Too Large” (or 413 FULL head) if it exceeds or you can also get a java.io.SocketException: Broken Pipe in the client side
============

I think the Jetty limit is something in the order of 4k, and apache has something similar. It's worth checking the constraints around whatever Web Server you are using.

I hope this helps in understanding the cause of the issue you've been seeing, additionally might be another reason to consider caching the 'original message' locally and simply passing a reference to that local cache in the Mule session when you make the CXF client call.

Reply all
Reply to author
Forward
0 new messages