CODEWITHSUNDEEP
httpmuleoutbound
Pavan JHNR
Pavan JHNR

Reputation: 49

Mule Read timed out exception

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>

Upvotes: 2

Views: 7309

Answers (2)

sakthi
sakthi

Reputation: 11

check server SO_TIMEOUT in httpconnection, set it to 0

check - https://www.mulesoft.org/jira/browse/MULE-6331

Upvotes: 1

David Dossot
David Dossot

Reputation: 33413

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).

Upvotes: 1

Related Questions