Jak wykryć przerwane/odzyskane połączenie JMS w Apache Camel?

Question

Budujemy projekt integracji za pomocą Apache Camel (Camel 2.10.3, oparty na Java DSL).

Mamy trasę, która wyodrębnia dane z bazy danych (pozwala nazywać je IN_DB), wykonuje niektóre operacje logiczne i wstawia do innej bazy danych (OUT_DB) raz dziennie i inną trasę, która subskrybuje temat JMS dla danych XML, trochę logiki i wstawia ją do tej samej bazy danych (OUT_DB) w ciągu dnia.

Wymaganie jest takie, że gdy połączenie z tematem JMS z jakiegoś powodu zanika, kontynuujemy próbę ponownego połączenia w nieskończoność, a po pomyślnym ponownym połączeniu musimy wrócić do bazy danych (IN_DB) i wykonać inne obciążenie, aby wypełnić luka, w której temat nie działa.

Moje pytanie brzmi: jak możemy zrobić tę logikę ("Byłem podłączony, a następnie zostałem odłączony, a teraz jestem połączony ponownie") w Camel? Co dzieje się z trasą zaczynającą się od tematu, gdy temat zostanie przerwany, czy trasa się skończy? Czy może wysłać komunikat o błędzie do kolejki błędów? Czy muszę napisać własny przewodnik do monitorowania połączenia z tematem, czy też Camel automatycznie ponownie się połączy, gdy wątek pojawi się ponownie i ustawić nagłówek komunikatu, lub ustawić zmienną kontekstową, aby wskazać, że "Byłem podłączony, a następnie zostałem odłączony i teraz Jestem połączony ponownie "? Cieszę się, budując logikę trasy wokół wywoływania obciążenia bazy danych Nie mogę po prostu znaleźć najlepszego sposobu "wykrycia" w Camel, że ten scenariusz się wydarzył.

Wszelkie sugestie bardzo doceniane.

Answer 1

Jeśli chodzi o ponowne połączenie z kolejką, zależy to od używanego brokera JMS. Jeśli korzystasz z ActiveMQ, możesz skonfigurować sposób ponownego łączenia się za pomocą identyfikatora URI, aby mógł spróbować ponownie połączyć się z innym brokerem, ponownie połączyć się z tym samym brokerem po przekroczeniu limitu czasu itp. Dokumenty do niego są here.

Aby wykryć, kiedy połączenie się nie powiodło, najłatwiejszym z punktu widzenia programu jest po prostu używanie trwałych kolejek zamiast tematów. Jednak zakładając, że nie jest to możliwe, myślę, że masz dwie opcje.

1. Zdefiniuj JMS exception listener. Powinno to dać ci znać, gdy zniknie podstawowe połączenie.

Aby wykryć, kiedy jego kopia zapasowa jest znowu, wydaje mi się, że utknąłeś z wysyłaniem wiadomości do określonego tematu i oglądaniem wiadomości z tego tematu na innej trasie. Po przeczytaniu wiadomości na ten temat wiadomo, że broker powrócił, aby można było ponownie załadować dane z bazy danych.

lub 2. Możesz wysyłać regularne wiadomości z tematem słyszenia do tematu JMS. Jeśli przestaniesz je otrzymywać, wiesz, że broker się zepsuł. Gdy zaczniesz je odzyskiwać, wiesz, że jest zapasowy i musisz przeładować dane z bazy danych.