Fatalfallbackerrorhandler вызывается, хотя handled имеет значение true - PullRequest
Новая
       43

Fatalfallbackerrorhandler вызывается, хотя handled имеет значение true

0 голосов
/ 03 апреля 2020

У меня есть верблюжий маршрут, как показано ниже. Хотя я установил handled (true), я не понимаю, почему defaulterrorhandler вызывает fatalfallbackerrorhandler после того, как все попытки были исчерпаны. 

onException(Exception.class)
    .handled(true)
    .to("direct:errors")          ----->  (1)
    ;                    

from("direct:errors")
    .log("hello world ");

from("timer:testRoute")
   .routeId("testRoute_1")
   .throwException(new Exception("Dummy Exception"))
   .pollEnrich("file://source")
   .to(http://localhost:8080)

Журналы:

20.04.03 11: 46: 53.907 INFO ad # 6 - таймер: // testRoute route1 BreadCrumbId = ID-xxxxxx-1585894556662-0-4 | привет мир

20.04.03 11: 46: 53.913 ОШИБКА ad # 6 - таймер: // testRoute mel.processor.DefaultErrorHandler BreadCrumbId = ID-xxxxxx-1585894556662-0-4 | Не удалось доставить (MessageId: ID-xxxxxx-1585894556662-0-5 для ExchangeId: ID-xxxxxx-1585894556662-0-4). Исчерпаны после попытки доставки: 4 поймано: java .lang.Exception: фиктивное исключение. Обработано обработчиком ошибок: FatalFallbackErrorHandler [Channel [sendTo (direct: // errors)]]

Если, я комментирую строку (1), defaulterrorhandler не вызывает fatalfallbackererhandhandler.

1 Ответ

0 голосов
/ 03 апреля 2020

Это выглядит совершенно правильно. Я даже пробовал это в тестовом классе, и он работал как вы ожидаете , таймер «генерирует» запись в журнале каждую секунду.

На самом деле это сообщение, пересылаемое на direct:errors, которое повторяется 5 раз и не удается. Это странно, потому что direct компонент является частью верблюжьего ядра.

Я бы предложил проверить зависимости вашего проекта. У вас есть разные JAR Camel с разными версиями на вашем classpath? Если вы используете Maven, вы можете попробовать подключаемый модуль Maven *1010* для проверки конфликтов путей к классам.

...