Достижение отказоустойчивого поведения в потоке

Я пытаюсь создать отказоустойчивый сценарий в своем потоке.

Мой поток выглядит следующим образом. Он включает в себя некоторые подпотоки, которые стажеры обращаются к веб-сервисам. В любом случае, если один из веб-сервисов недоступен, возникает исключение отказа в соединении, и вся обработка останавливается.

Вместо этого мне нужен отказоустойчивый сценарий, в котором поток должен продолжаться со следующими подпотоками, даже если текущий исходящий вызов завершается сбоем.

Есть ли какой-либо процессор сообщений или процессор управления потоком, который может помочь добиться такого поведения в Mule.

Ниже приведен мой абстрактный поток

<flow name="main_flow" >
    ....
    ....
    <flow-ref  name="subflow_1" />
    ....
    ....
    <flow-ref  name="subflow_2" />
    ....
    ....
    <flow-ref  name="subflow_3" />
    ....
    ....

</flow>

<sub-flow name="subflow_1">
    ....
    ....
    <out-bound call to web-service />
    ....
    ....
</sub-flow>

<sub-flow name="subflow_2">
    ....
    ....
    <out-bound call to web-service />
    ....
    ....
</sub-flow>

<sub-flow name="subflow_3">
    ....
    ....
    <out-bound call to web-service />
    ....
    ....
</sub-flow>

java mule flow
person user1760178    schedule 01.02.2013    source источник
comment
Зависят ли взаимодействия подпотоков друг от друга? Если нет, вы можете распараллелить их, и каждый умрет по отдельности.   -  person David Dossot    schedule 01.02.2013
comment
Они какие-то зависимые. В каждом подпотоке мне нужно извлечь некоторые данные из ответа веб-службы и добавить их во входную полезную информацию. Затем это становится полезной информацией для следующего подпотока.   -  person user1760178    schedule 01.02.2013
comment
Как вы сказали, результат одного подпотока становится полезной нагрузкой для другого подпотока, тогда не имеет особого смысла вызывать второй подпоток без получения ответа от первого.   -  person Charu Khurana    schedule 01.02.2013
comment
@Learner прав: если взаимодействия подпотока зависят, то зачем продолжать основной поток, если вы не можете получить данные, необходимые для продолжения?   -  person David Dossot    schedule 01.02.2013
comment
Как я уже сказал, это своего рода обогащение без непосредственного использования обогатителя. Потому что обогащение основано на некоторой логике. Это похоже на то, что ввод сохраняется. в каждом подпотоке создается запрос из полезной нагрузки, подходящей для вызова веб-сервиса. Затем из ответа извлекаются необходимые данные и обогащаются в сохраненную входную полезную нагрузку. Затем этот обогащенный paylaod устанавливается как Paylaod для следующей части.   -  person user1760178    schedule 02.02.2013

Ответы (3)


arrow_upward
1
arrow_downward

Вы можете добиться отказоустойчивого поведения с потоками.

<flow name="main_flow" >
    ....
    ....
    <flow-ref  name="flow_1" />
    ....
    ....
    <flow-ref  name="flow_2" />
    ....
    ....
    <flow-ref  name="flow_3" />
    ....
    ....

</flow>

<flow name="flow_1" processingStrategy="synchronous" >
    ....
    ....
    <out-bound call to web-service />
    ....
    <catch-exception-strategy >
      .... Your FailSafe code to recover. Also you will have the exception here.
     </catch-exception-strategy>
</flow>

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

Удачного кодирования :)

person Community    schedule 14.03.2013

arrow_upward
1
arrow_downward

Одним из способов взлома может быть сохранение полезной нагрузки в переменной, наличие блока <catch-exception-strategy>, который будет перехватывать исключение вызова веб-службы, использование <set-payload> для перезаписи текущей полезной нагрузки, а затем вызов sub-flow2 вручную из catch-exception потока sub-flow1

person Charu Khurana    schedule 01.02.2013
comment
Это решение я уже пробовал. Но это становится более громоздким. Вот почему ищите, есть ли у Mule такие процессоры, которые могут помочь. - person user1760178; 02.02.2013
comment
Также подпоток не имеет собственной стратегии исключения. - person user1760178; 02.02.2013
comment
Да, вам придется использовать частные потоки. - person David Dossot; 02.02.2013
comment
Большое спасибо @Learner. - person user1760178; 02.02.2013

arrow_upward
1
arrow_downward

Для каждого вызова веб-службы используйте first-successful маршрутизатор, в котором ваш вызов веб-службы является первым дочерним элементом, а резервный механизм - вторым.

person David Dossot    schedule 01.02.2013
comment
Но обработка после вызова веб-сервиса в подпотоке не требуется, если вызов веб-сервиса не удался. В этом случае мой поток должен перейти от конечной точки вызова веб-службы (которая не удалась) к моему основному потоку, который затем переходит к остальным потокам. Но как я могу использовать для этого first-successful. - person user1760178; 02.02.2013
comment
Если вызов веб-службы завершится ошибкой, остальная часть подпотока не будет выполнена. Вместо этого включится второй обработчик сообщений в first-successful, что позволит вам предоставить любые данные по умолчанию/фальшивые/нулевые в случае сбоя вызова. - person David Dossot; 02.02.2013
comment
Я могу это сделать. ‹first-successful› ‹flow-ref name=SubFlow_1›‹/flow-ref› ‹set-payload value=#[flowVars['preSubFlowPayload']]›‹/set-payload› ‹/first-successful› - person user1760178; 02.02.2013
comment
Большое спасибо, Дэвид. - person user1760178; 02.02.2013
comment
У меня проблема с этим подходом. Когда подпоток терпит неудачу, используя first-successful, я перехожу к следующему шагу. Но перед этим мне нужно сделать что-то в соответствии с Exception. Но я не могу получить исключение. Любая идея, как я могу получить exceptionPaylaod. - person user1760178; 11.02.2013