Исключения из маршрутов с использованием параллельной обработки - PullRequest
0 голосов
/ 19 сентября 2018

У меня есть три "уровня" маршрутов:

  • direct: начало - это простой маршрут, который "вызывает" direct: middle
  • direct: middle имеет многоадресную / параллельную обработку, вызываядва других
  • два других маршрута (на третьем уровне) оба генерируют исключения

Этот пример заставляет эти два маршрута самого низкого уровня генерировать исключения.При кодировании, как показано ниже, я вижу два исключения (напечатано, как показано в onException ())

public void configure() throws Exception {

onException().handled(true).log(" ---------------   Exception!!  -------------------------");

from("direct:start")
 .log("Actual start ")
 .inOut("direct:middle")
 .log(" ---------------   Caught Exception -------------------------")
 .log("Actual End ");


from("direct:middle")
//.errorHandler(noErrorHandler())
.log("after direct:start body=${body}")
.multicast(new MyAggregationStrategy()).parallelProcessing().stopOnException()
  .to("direct:A")
  .to("direct:B")
.end();

from("direct:A").errorHandler(noErrorHandler()).process(new ExceptionThrower());
from("direct:B").errorHandler(noErrorHandler()).process(new ExceptionThrower());

}

I UN -прокомментировал noErrorHandler () в "direct: middle", полагая, что он все еще может запускать onException (), но только с одним исключением.Вместо этого он действовал так, как будто не было никакого onException (), указанного в RouteBuilder, отбрасывая Исключение полностью назад к вызывающей стороне.

Мне интересно понять, почему это происходит.Я попытался использовать doTry () ... doCatch () во внешнем маршруте, и это, похоже, сработало, но я не уверен, почему другой подход не работает.

1 Ответ

0 голосов
/ 19 сентября 2018

Вы правы.Я пришел к тем же выводам, что и вы (несколько лет назад, но я не думаю, что это изменилось).На самом деле, обработка ошибок / исключений (не говоря о распространении) является IMHO самой (может быть, мощной, но все же) запутанной вещью в Camel.

Согласно документу, без указания обработчика ошибокв маршруте заставит ваш маршрут неявно использовать DefaultErrorHandler, поведение которого:

По умолчанию любое исключение, выброшенное во время маршрутизации, будет передано обратно вызывающей стороне, и Exchange немедленно завершится

Это правда ... пока вы остаетесь на том же маршруте!Если вы хотите распространить исключение в подчиненном маршруте («direct: middle») обратно на маршрут вызова («direct: start»), вы действительно HAVE представите:

.errorHandler(noErrorHandler() )

Теперь для EIP групповой адресации / split / receientList не забывайте, что они работают на копиях оригинального Exchange.Любая ошибка в копии не влияет на «основной» обмен.Если вам нужна эта функциональность, активируйте «shareUnitOfWork» (или внедрите умную стратегию агрегации, которая объединяет потенциальные исключения на подменях в уникальное исключение)

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