Co najlepiej zrobić w sytuacji gdy mamy serwis A, który komunikuje się synchronicznie z B, serwis B poprawnie wykonał transakcje ale A z powodu timeoutu zakmnął połączenie i zwrócił błąd dla klienta mimo, że transakcja w B wykonała się poprawnie?
0
0
Zanim wyślesz błąd do użytkownika to lepiej ponowić odpytanie serwisu B.
2
- Może warto ustawić timeouty sensownie, tzn timeout na wykonanie operacji w B niech będzie niższy niż timeout oczekiwania A na odpowiedź B?
- Zrobić to asynchronicznie? Niech A czeka na callback z B tak długo jak będzie trzeba?
0
timeout na wykonanie operacji w B niech będzie niższy niż timeout oczekiwania A na odpowiedź B?
Da się ustawić timeout w B dla całej operacji? Co jeżeli B odczytuje dane z 3 innych serwisów dodatkowo coś na podstawie tego przetwarza i zapisuje do bazy? Wtedy to jest kilka operacji ciężko dobrać odpowiedni timeout w A. Dodatkowo B może być bardziej obciążony i przetwarzanie może zająć dłużej niż zwykle ale się uda.
0
Możesz zrobić coś w rodzaju wewnętrznego pinga, który sprawdzi, czy polecenie wykonuje się czy ‚stoi’ na czymś. Wtedy istotne byłby timeouty na połączeniach B do innych serwisów, chyba że tam też byłby używany ping, lub timeouty na mikrooperacjach.
0
Jak masz komunikację synchroniczną, to właściwie możesz tylko poczekać. Czyli request do A powinien mieć dłuższy timeout niż z A do B. Pytanie jeszcze, czy nie musisz posprzątać po tej operacji.
0
Ja bym zwiekszyl timeout, tylko w granicy przyzwoitości - nie wiekszy niz wolajacy Twoj serwis (powinni powiedziec jaki macie „budzet”, bo w ogolnosci moga wolac wiele zaleznosci) i rzedu wielkosci <50-100ms. Do tego retry’e i idempotentny zapis. Jezeli operacja musi trwac dluzej, to zdecydowanie async.