Kolejka JMS jest pełna

Question

Moja aplikacja Java EE wysyła JMS do kolejki w sposób ciągły, ale czasami aplikacja klienta JMS przestała otrzymywać JMS. Powoduje to, że kolejka JMS jest bardzo duża, nawet pełna, co powoduje zwinięcie serwera. Mój serwer to JBoss lub Websphere. Czy serwery aplikacji udostępniają strategię usuwania komunikatów JMS z limitem czasu?

Co to jest strategia obsługi dużej kolejki JMS? Dzięki!

Answer 1

Przy każdym asynchronicznym przesyłaniu wiadomości musisz uporać się z problemem "szybki producent/wolny konsument". Istnieje wiele sposobów radzenia sobie z tym.

1. Dodaj konsumentów. W produkcie WebSphere MQ można wyzwalać kolejkę na podstawie głębokości. Niektóre sklepy używają tego do dodawania nowych instancji konsumenckich wraz ze wzrostem głębokości kolejki. W miarę jak głębokość kolejki zaczyna spadać, dodatkowy konsument umiera. W ten sposób można dokonać automatycznej zmiany wagi w celu dostosowania do zmieniających się obciążeń. Inni brokerzy mają na ogół podobną funkcjonalność.
2. Uczyń kolejkę i podstawowy system plików naprawdę dużym. Ta metoda próbuje wchłonąć szczytowe obciążenia w całości w kolejce. Jest to przecież przede wszystkim zadanie kolejkowania. Problem polega na tym, że nie skaluje się dobrze i musisz przydzielić dysk, który w 99% czasu będzie prawie pusty.
3. Wygasają stare wiadomości. Jeśli wiadomości mają ustawiony okres ważności, możesz je usunąć. Niektórzy brokerzy JMS robią to automatycznie, podczas gdy inni mogą potrzebować przeglądać kolejkę, aby usunąć wygasłe wiadomości. Problem polega na tym, że nie wszystkie wiadomości tracą wartość biznesową i kwalifikują się do wygaśnięcia. Większość wiadomości typu "fire-and-forget" (dzienniki kontroli itp.) Należą do tej kategorii.
4. Przepustnica z powrotem producenta. Gdy kolejka się zapełni, nic nie może umieścić w niej nowych wiadomości. W produkcie WebSphere MQ aplikacja generująca otrzymuje kod powrotu wskazujący, że kolejka jest pełna. Jeśli aplikacja rozróżnia błędy krytyczne i przejściowe, może zatrzymać się i ponowić próbę.

Kluczem do pomyślnego wdrożenia dowolnego z nich jest to, że twój system może dostarczać "miękkie" błędy, na które aplikacja będzie reagować. Na przykład wiele sklepów podniosą parametr MAXDEPTH kolejki, gdy po raz pierwszy otrzymają stan QFULL. Jeśli głębokość kolejki przekracza rozmiar bazowego systemu plików, wynikiem jest to, że zamiast "miękkiego" błędu, który wpływa na pojedynczą kolejkę, system plików zapełnia się i dotyczy całego węzła. DUŻO lepiej jest dostroić system, tak aby kolejka trafiała MAXDEPTH na długo przed wypełnieniem systemu plików, ale potem również instrumentować aplikację lub inne procesy, aby w jakiś sposób zareagować na pełną kolejkę.

Ale bez względu na to, co jeszcze zrobisz, opcja nr 4 powyżej jest obowiązkowa. Bez względu na to, ile przydzielasz dyskowi lub ile wdrożeń konsumenckich zainstalujesz lub jak szybko wygasają wiadomości, zawsze istnieje możliwość, że Twoi konsumenci nie nadążają za tworzeniem wiadomości. Kiedy to nastąpi, twoja aplikacja producencka powinna cofnąć przepustnicę, lub podnieść alarm i zatrzymać się lub zrobić coś innego niż powieszenie lub śmierć. Wiadomości asynchroniczne są tylko asynchroniczne do momentu, w którym zabraknie miejsca na kolejkowanie wiadomości. Potem twoje aplikacje są synchroniczne i muszą z wdziękiem poradzić sobie z tą sytuacją, nawet jeśli oznacza to (z gracją) zamknięcie.

Answer 2

Jasne!

http://download.oracle.com/docs/cd/E17802_01/products/products/jms/javadoc-102a/index.html Message#setJMSExpiration(long) robi dokładnie to, co chcesz.