Во многих документах говорится, что catch-exception-стратегии похожа на блокировку java. Но, к сожалению, полезная нагрузка израсходована (сообщение израсходовано); из блока catch полезная нагрузка теряется (в отличие от метода java, где вы можете получить доступ к входным параметрам метода из блока catch / finally).

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

Предположим, что если есть поток с 10 обработчиками сообщений, становится утомительно определять обработчик сообщений, который выдал ошибку.

Я вижу 2 обходных пути относительно полезной нагрузки:
1) После входящей конечной точки передавайте полезную нагрузку в переменную потока перед каждым обработчиком сообщений (опять же, еще один недостаток - что происходит с входящими свойствами и вложениями?)
2) Используйте стратегию исключения отката с нулевыми попытками (транзакция будет отменена), и исходное входное сообщение может быть доступно. (недостаток: трудно понять, почему произошла ошибка и на каком процессоре сообщений - пример: у меня может быть 5 или 6 процессоров БД)

Причина, по которой это становится важным, заключается в том, что поддержка приложения ESB в производстве становится проще.

Например, из блока catch, если нам удастся передать данные полезной нагрузки и исключений (связанные с одним UID), вы можете запустить инструмент мониторинга журналов и перенести его на панель мониторинга в реальном времени для целей мониторинга / оповещений. Один и тот же подход может быть применен ко всем приложениям / потокам, компонентам Java и т. Д.

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

Мои вопросы: 1) Есть ли причина, по которой полезная нагрузка становится недоступной? Возможный обходной путь состоит в том, чтобы передать (последние известные данные) в другую переменную как часть сообщения под названием originalPayload или originalInboundProperties? 2) Любой другой прямой способ передачи исключения и полезной нагрузки аппендиру (вместо обходных путей)?

Анант Кришнан (WHISHWORKS.com)