Http Mule读取超时异常

我有一个esb，我可以从中调用webservice，它在大多数情况下运行良好，但有时会出现以下异常

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)

奇怪的是，在我得到这个异常之后，有时http出站调用仍然成功，有时不成功

为什么这不一致

mule http connector上的某些配置是否有可能帮助此异常场景保持一致

我所要求的是。。。如何在引发读取超时异常后停止处理http出站请求

流程如下图所示

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

....  一些转换逻辑
....
....
....  关于响应的一些转换逻辑。。。
……关于响应的一些转换逻辑。。。
.... 不可靠的…结果。。。正如FirstWebServiceCall可能会成功，即使在控件到达这里之后
如果我们处理http://localhost:8080/firstwebservicecall .. 交易发生两次。。。如上所述，即使在抛出异常后，它也已成功
..... 可靠的。。。如果控制在这里，如果我们处理http://localhost:8080/secondWeberviceCall .. 交易只发生一次
……可靠
……可靠

您可以在不同的位置配置并增加HTTP传输的超时时间：

• ,

不过，这只是进一步推动了问题：增加超时时间可能会暂时解决您的问题，但您仍然面临失败的风险

为了正确地处理它，我认为您应该在每个HTTP出站端点之后严格检查响应状态代码，如果状态代码不是您期望的，那么可以使用

过滤器来中断流

此外，在服务器接收到HTTP请求之后，在响应返回Mule之前，您很可能会得到一个响应超时。在这种情况下，就Mule而言，调用失败，必须重试。这意味着远程服务必须是幂等的，即客户端应该能够安全地重试任何失败的操作（或它认为失败的操作）。
检查httpconnection中的服务器超时，将其设置为0

选中-
您是否可以共享您的流配置。获取上下文会更容易。是否检查每个
http:outbound endpoint
之后收到的状态代码？我没有检查。。但我想它应该是500，因为它落在了捕鲸区。。但是当我检查数据库时，oubound调用被证明是成功的。。所以我不再在catch块中处理firstwebservicecall，它解决了业务逻辑。。。但从技术上讲，我觉得这是错误的……如果我理解正确，
readTimeOut
发生在您的
firstwebservicecall
和
secondwebservicecall
成功。是否正确？感谢您的快速回复，根据您的建议，我检查了http状态代码，并观察到它在进入catch exception strategy时有时为200，有时为null，但根据数据库结果检查，在套接字超时异常的情况下，它们中的任何一个都不能证明在服务器请求接受方面是一致的，或者不一致的。在出现此读取超时异常的情况下，是否有任何方法可以检查服务器是否接收到客户端请求？？？关于服务器端的幂等实现（在我的例子中，它只是另一个调用Web服务的esb）。。如果是，你建议使用吗？你能给我一个这个实现的大致想法吗？谢谢我不确定我是否明白你的意思：你是说即使抛出异常，你有时也可以得到200？是的，David，我很惊讶地看到在负载测试场景下的catch exception策略中Http状态等于200或null。。例如：-如果5000条记录在vm队列中，并通过vm:inbound进入如上图所示的流，我会为少数记录（如2条或3条）获得此读取超时异常，在这2条或3条记录中，少数记录的http状态为200，其他记录在catch Block中为null，我在流上配置了2个线程，如上图所示。谢谢！帮助其他人找到设置。编辑连接器配置，转到“计时”选项卡，将客户端SO_超时和服务器SO_超时设置为0。