|
|
Opublikowano 09.04.2018 10:23:21
|
|
|
|

Domyślnie wiadomości kolejki rabbitMQ nie są utrzymywane na dysku twardym, co oznacza, że po ponownym uruchomieniu usługi rabbitMQ wiadomości zostaną utracone.
Utrzymywanie kolejek
Na przykład identyfikacja trwałości kolejki jest identyfikowanadurableis ustawiony na true, co oznacza, że jest to kolejka trwała, a po wznowieniu usługi również będzie istnieć, ponieważ usługa przechowuje kolejkę na dysku twardym, a po jej wznowieniu ponownie ustanawia to, co było wcześniej utrzymane w kolejce. Kolejka może być utrzymana, ale to, czy wiadomości w niej są trwałe, zależy od ustawień trwałości wiadomości. Innymi słowy, jeśli przed ponownym uruchomieniem nie wysłano żadnej wiadomości w kolejce, to czy oryginalna wiadomość nadal istnieje w kolejce po ponownym uruchomieniu, zależy od ustawień wiadomości, które pojawiły się w momencie wysłania wiadomości. Jeśli chcesz, aby wiadomości trwały po wznowieniu, musisz ustawić tożsamość, że wiadomość jest trwała.
Ustaw trwałość kolejki:
Czwarty parametr metody, autoDelete, zwykle jest wpisywany jako false. Dokumentacja opisuje ten parametr, jeśli jest prawdziwy, co oznacza, że jeśli kolejka nie jest już używana (nie jest subskrybowana), serwer ją usunie. Podczas moich testów, dopóki wszyscy odbiorcy kolejki zmiany połączenia są odłączeni, kolejka jest usuwana, nawet jeśli nadal są w niej nieprzetworzone wiadomości. Restarty RabbitMQ również je usuną. Jeśli zostanie wprowadzony fałszywy wpis, usługa nie usunie kolejki, a wiadomości w kolejce będą istnieć, jeśli wszyscy klienci do niej podłączoni zostaną rozłączeni. Nadawca może także umieszczać wiadomości w kolejce zmian, gdy nie ma połączenia z klientem, a gdy klient się pojawi, otrzyma te wiadomości. Jednak jeśli usługa RabbitMQ zostanie zrestartowana, kolejka zniknie, a komunikaty w niej naturalnie znikną.
Trzeci parametr jest wyłączny, a dokumentacja stwierdza, że jeśli jest prawdziwe, połączenie kolejki zostaje przerwane, a kolejka jest usuwana, włącznie z komunikatami w środku.
Drugi parametr, trwały, jest opisany w dokumentacji jako mówiący, że jeśli jest prawdziwy, reprezentuje trwałą kolejkę, która będzie istnieć także po wznowieniu usługi. Ponieważ usługa przechowuje trwałą kolejkę na dysku twardym, a po jej ponownym uruchomieniu potwierdzi tę kolejkę. Oczywiście, musi tak być, gdy zarówno autoDelete, jak i exclusive są fałszywe. Kolejka może być utrzymana, ale to, czy wiadomości w niej są trwałe, zależy od ustawień trwałości wiadomości. Innymi słowy, jeśli wiadomości nadal są wysyłane w kolejce przed restartem, to czy oryginalna wiadomość nadal istnieje w kolejce po wznowieniu, zależy od ustawień nadawcy dla wiadomości podczas jej wysyłania.
Po modyfikacji kodu próbujemy go uruchomić, a błąd będzie następujący:
Nieobsługiwany wyjątek: RabbitMQ.Client.Exceptions.OperationInterruptedException: Operacja AMQP została przerwana: AMQP close-reason, inicjowana przez Peer, code=406, text="PRECONDITION_FAILED - nierównoważny arg 'durable' dla kolejki 'hello' w hostie 'myserver': otrzymane 'true', ale current is 'false'", classId=50, methodId=10, cause=
Ponieważ zdefiniowaliśmy kolejkę bez trwałości o nazwie hello. RabbitMQ nie pozwala na redefiniowanie istniejących kolejek z innymi ustawieniami parametrów.
Istnieją dwa rozwiązania:
1: Ponownie zadeklarować kolejkę pod inną nazwą, na przykład my_queue 2: Usuń zdefiniowaną kolejkę "hello" z adresem http://localhost:15672 i zaloguj się za pomocą nazwy użytkownika i hasła. Domyślne hasło i nazwa użytkownika RabbitMQ to gościnne. Kliknij kolumnę "kolejka", aby zobaczyć listę kolejek, kliknij na kolejkę "hello", aby rozwinąć szczegóły kolejki. Przeciągnij stronę na koniec, jest tam element "Usuść", kliknij go, kliknij przycisk "Usuń kolejkę" i możesz usunąć kolejkę. Następnie, gdy kod jest uruchamiany, tworzona jest kolejka powitań wspierająca trwałość.
Utrzymywanie wiadomości
Jeśli chcesz, aby wiadomość pozostała trwała po wznowieniu, musisz ustawić ją na trwałość. Ustawienie to moment, gdy nadawca go wysyła, co jest stosunkowo proste, a kod wygląda następująco:
DeliveryMode domyślnie ustawia się na 1, nietrwały, a ustawienie na 2 oznacza, że wiadomość jest trwała
Po modyfikacji kodu staramy się otwierać program Producer tylko do wysyłania wiadomości, a następnie restartować usługę rabbitMQ, ponownie otworzyć konsumenta i okazuje się, że komunikat nie został utracony.
(Koniec)
Załączony jest kod źródłowy C#:
Turyści, jeśli chcecie zobaczyć ukrytą zawartość tego wpisu, proszę Odpowiedź
|
Poprzedni:Wiadomość wyjątku: "StrongTypingException: IsPrima...Następny:Wprowadzenie do delegatów C# (delegate, Action, Func, predykat)
|