[Patres]

#java #queue #programowanie
Mirki, czy widzicie jakieś zalety w użyciu kolejki zamiast REST ale w przypadku gdy mamy tylko komunikację synchroniczną (czekamy na odpowiedź). Mam w projekcie takie przypadki i zastanawiam się czy ma to w ogóle jakiś sens

[Saly]

@Patres: w oganiętym systemie: nie. Kiedy to może mieć sens? Jak większość zapytań idzie przez kolejki to przepchanie tych synchronicznych zapytań może mieć sens, bo wtedy system zachowuje się tak samo dla każdego zapytania, więc masz uproszczone debugowanie, logowanie, monitoring itd. Z drugiej strony śledzenie takiej synchronicznej tranzakcji, która jest przepychana przez kolejkę jest dużo bardziej skomplikowane

Inne zalety to load balancing i retry, które masz za darmo (ale to

[LazyInitializationException]

@Patres: Łatwiej można ogarnąć high-availability i o ile jakiś retry po http to pewnie można trwać z minutę to na kolejce może i godzinami/dniami leżeć event aż go przerobi odpowiedni serwis gdy w końcu zacznie działać. Oprócz tego odciąża to zasoby bo jak serwis robi retry po http to normalnie zużywa na to wątek, a tak to wysyła event na kolejkę i elo

[fujiyama]

@Patres: lepszy decoupling.
Jak wysyłasz event to możesz potem dopisać łatwo kolejną reakcję na zdarzenie gdziekolwiek w serwisie lub innym serwisie.
Przy "czystym" rest musisz rozszerzać istniejący handler. I zaraz się okaże, że Twój rest musi zrobić 5 rzeczy na raz.
Generalnie jest więcej za niż przeciw w przypadku większych rozwiązań.

[Saly]

to na kolejce może i godzinami/dniami leżeć event aż go przerobi odpowiedni serwis gdy w końcu zacznie działać.

@LazyInitializationException: ale pytanie było o synchroniczne calle.

Oprócz tego odciąża to zasoby bo jak serwis robi retry po http to normalnie zużywa na to wątek, a tak to wysyła event na kolejkę i

[LazyInitializationException]

@Saly:

ale pytanie było o synchroniczne calle.

Nie szkodzi. W takiej sytuacji użycie brokera też zwiększa high

[fujiyama]

@Saly: przecież masz ją w kodzie. Kolejka tylko zarządza priorytetem, przechowuje i rozsyła zdarzenia.
A architektura robi się skomplikowana, serwisy muszą komunikować się ze sobą, po jakimś czasie wszystko zaczyna gadać ze wszystkim. Każda głupia funkcja musi nagle przechowywać kolejkę, robić retry itd.
Przerabiałem to, na koniec nie wiadomo co się stało, kto nie dostał albo nie przetworzył.

[Patres]

@LazyInitializationException: @fujiyama @Saly Dzięki za dyskusje! Będąc szczerym nie do końca jestem przekonany czy kolejki w tym przypadku mają sens (co nie oznacza się z Wami nie zgadzam):

Łatwiej można ogarnąć high-availability i o ile jakiś retry po http to pewnie można trwać z minutę to na kolejce może i godzinami/dniami leżeć event

Teoretycznie tak, ale w praktyce consumer raczej nie będzie tyle czekać i też zakończy się to

[Saly]

ale praca przy kolejkach w Apache Camel sprawia że dostaję migrenę

@Patres: taki już jest camel. Słabe typowanie (wszystko to Message) plus uwspólnianie każdego możliwego protokołu do Map<String, Object> nie jest miłe w developowaniu