Mule Read timed out exception

Question

I have an esb from which i make a webservice call,which works fine most of the times, but sometimes i get the below exception

java.net.SocketTimeoutException: Read timed out
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:129)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
    + 3 more (set debug level logging or '-Dmule.verbose.exceptions=true' for everything)

the weird thing is after i get this exception, some times the http outbound call still succeeds and some times does not succeed

why is this not consistent?

is there a chance that some configuration on mule http connector can help this exception scenario behave consistently?

All i am asking is... how to stop the http outbound request from getting processed after a read timed out exception is thrown?

the flow looks like below shown code

<queued-asynchronous-processing-strategy name="allow2Threads" maxThreads="2"/>

<flow name="TestFlow" processingStrategy="allow2Threads">
     <vm:inbound-endpoint path="performWebserviceLogic" exchange-pattern="one-way" />

    ....  some transformation logic
    ....
    <http:outbound-endpoint address="http://localhost:8080/firstwebservicecall" responseTimeout="65000" exchange-pattern="request-response"/>
    ....
    ....  some transformation logic on response...
    <http:outbound-endpoint address="http://localhost:8080/secondWeberviceCall" responseTimeout="20000" exchange-pattern="request-response"/>
    ......some transformation logic on response...

    <catch-exception-strategy>
        <choice>
            <when expression="#[groovy:message.getExceptionPayload().getRootException.getMessage().equals('Read timed out') and message.getSessionProperty('typeOfCall').equals('firstWeberviceCall')]">
                    .... unreliable ...result... as firstWeberviceCall may succeed even after the control comes here
                    and if we process http://localhost:8080/firstwebservicecall .. the transaction takes place twice... as already it succeeded above even after an exception is thrown
            </when>
            <when expression="#[groovy:message.getExceptionPayload().getRootException.getMessage().equals('Read timed out') and message.getSessionProperty('typeOfCall').equals('secondWeberviceCall')]">
                    ..... reliable ... if control comes here and if we process http://localhost:8080/secondWeberviceCall .. the transaction takes place only once
            </when>
            <when expression="#[groovy:message.getExceptionPayload().getRootException.getMessage().equals('Connect timed out') and message.getSessionProperty('typeOfCall').equals('firstWeberviceCall')]">
                ....reliable
            </when>
            <when expression="#[groovy:message.getExceptionPayload().getRootException.getMessage().equals('Connect timed out') and message.getSessionProperty('typeOfCall').equals('secondWeberviceCall')]">
                ....reliable
            </when>
        </choice>
    </catch-exception-strategy>   
</flow>

Can you share your flow configuration. It would be easier to grab your context. — Ram Bavireddi
Do you check the status code received after each http:outbound-endpoint? — David Dossot
i did not check it.. but i guess it should be 500 as it landed in catch block.. but the oubound call proves to be successful when i check the database.. so iam not processing firstwebservicecall again in catch block which solves the business logic ... but technically it is wrong i feel... — Pavan JHNR
If I understood correctly, readTimeOut occurred for your firstwebservicecall and secondWeberviceCall got succeeded. Is it correct? — Ram Bavireddi

David Dossot David Dossot · Accepted Answer · 2015-02-18T16:13:00

You can configure, thus increase, the time-outs of the HTTP transport in different places:

This is just pushing the problem further though: increasing the time-outs may solve your issue temporarily but you're still exposed to the failure.

To handle it properly, I think you should strictly check the response status code after each HTTP outbound endpoint, using maybe a filter to break the flow if the status code is not what you expect.

Also, it's well possible that you get a response time out after the HTTP request has been received by the server and before the response gets back to Mule. In that case, as far as Mule is concerned, the call has failed and must be retried. Which means the remote service must be idempotent, i.e. the client should be able to safely retry any operation that failed (or it thinks has failed).

Mule Read timed out exception

2 Answers