Mule Read таймаут исключение

У меня есть ESB, из которого я сделать WebService вызов, который отлично работает в большинстве случаев, но иногда я получаю НИЖЕ за исключениемMule Read таймаут исключение

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-исходящий вызов по-прежнему преуспевает и несколько раз не удается

Почему это не соответствует?

есть ли вероятность того, что некоторая конфигурация на соединителе http-мула может помочь этому сценарию исключений вести себя последовательно?

Все, что я прошу, это ... как остановить 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>

источник

2015-02-17 Pavan JHNR

Вы можете поделиться конфигурации потока. Было бы легче захватить ваш контекст. –

Вы проверяете код состояния, полученный после каждого 'http: outbound-endpoint'? –

Я не проверял его .. но я думаю, что он должен быть 500, когда он приземлился в блоке catch. Но вызов oubound оказывается успешным, когда я проверяю базу данных. Поэтому iam не обрабатывает firstwebservicecall снова в блоке catch, который решает бизнес-логика ... но технически это неправильно, я чувствую ... –

Вы можете настроить, таким образом, увеличить, тайм-аут на HTTP транспорта в разных местах:

Это только толкает проблему дальше: увеличение тайм-аутов может временно решить проблему, но вы по-прежнему подвергаетесь сбою.

Для правильной работы с ним я должен строго проверить код состояния ответа после каждой исходящей конечной точки HTTP, используя, возможно, filter, чтобы разбить поток, если код состояния не соответствует ожидаемому.

Кроме того, вполне возможно, что вы получите время ответа после получения HTTP-запроса сервером и до того, как ответ вернется в Mule. В этом случае, что касается Мула, вызов завершился неудачей и его необходимо повторить. Это означает, что удаленная служба должна быть идемпотентной, т. Е. Клиент должен иметь возможность безопасно повторять любую операцию, которая потерпела неудачу (или она считает, что она не удалась).

источник

2015-02-18 16:13:00

Спасибо за ваш быстрый ответ, Как я уже сказал, я проверил код статуса http и заметил, что он несколько раз 200, как только он ввел catch-exception-strategy и несколько раз null, но на основании проверки результата базы данных ни один из они оказываются согласованными при принятии запроса на сервер или нет в случае исключения тайм-аута сокета –

есть ли способ проверить, что сервер сделал или не получил клиентский запрос в случае этого исключения таймаута чтения ??? относительно идемпотентной реализации серверной части (в моем случае это просто еще один esb, вызывающий веб-сервис) .. Вы предлагаете использовать http://www.mulesoft.org/docs/site/current/apidocs/org/mule/routing/IdempotentMessageFilter.html , если да, вы можете просто дать мне общую идею этой реализации. Спасибо –

Не уверен, что я следую за вами: вы говорите, что иногда вы можете получить 200, даже если исключение выбрано? –

проверка сервера SO_TIMEOUT в HttpConnection, установите его в 0

проверка - https://www.mulesoft.org/jira/browse/MULE-6331

источник

2015-02-25 10:45:21 sakthi

Спасибо! Чтобы помочь другим найти настройки. Измените конфигурацию коннектора, перейдите на вкладку Timings, установите для клиента SO_TIMEOUT и Server SO_TIMEOUT значение 0. – GarethPN

Mule Read таймаут исключение

ответ

Смежные вопросы