Kolejkowanie zapytań do API

0

Witam.
Kolejny dzień kolejne pytania. Potrzebuje pomocy w przypadku kolejkowania zapytań do API. W związku z tym, że operacje (nie moje dll) są bardzo "czułe", jeśli tak można to okręślić, to muszę dać czas na wykonanie się poprzedniego zapytania, aby kontynuować z następnym. Probowałem Hangfire, ale niestety potrzebuje coś zwrócić z API do klienta, a tutaj Pan wyjaśnił dlaczego nie powinno się tego robić z Hangfire How to catch return object from BackgroundJob.Enqueue()?

Z czego korzystacie? Może API nigdy nie potrzebuje kolejkować zadań.

  1. Projekt jest wewnętrzny, pisany specjalnie pod konkretne zadania.
  2. Nikt z zewnątrz do tego API się łączyć nie będzie.
  3. Nie mogę kolejkować zapytań do API po stronie klienta, ponieważ problem jest gdy mam dwóch lub więcej i chcą zrobić coś w tym samym czasie.
  4. Asynchroniczność i synchroniczność też nic nie dają. Jeden z klientów jest odrzucany przez API. Debugowanie asynchronicznych metod powoduje u mnie ból istnienia.
0

Opakuj API w kolejkę i konsumenta, który będzie brał z kolejki szczegóły żądania, wykonywał je, a wyniki zapisywał w znanym miejscu. Klient dostaje ID wiadomości z kolejki, potem może spokojnie czekać na odpowiedź (czy to w jakimś pliku, czy w bazie, czy inaczej powiadomiony), może też regularnie odpytywać, możesz też postawić dowolnego pubsuba i krzyczeć, gdy przetwarzanie będzie zakończone.

0

Potrzebuje szybszej odpowiedzi, nie mogę czekać nie wiadomo ile, albo wziąć sobie odpowiedź skądś tam. Najlepsze by było jakbym mógł zatrzymać przyjmowanie requestów na czas przetwarzania bieżącego. Na tą chwilę spodziewam się, że mogę mieć max 3 klientów, którzy mogą (ale nie muszą) zapytać API o to samo w tym samym czasie. Problemy są przy dwóch, a nie chce jakiś głupot robić i tracić czas.

0

No to niech klient ma timeout i nie czeka na odpowiedź dłużej, a konsument ignoruje stare wiadomości.

0

w sensie chcesz przetwarzać tylko jedn request jednocześnie i nie modyfikować w żaden sposób klienta? No to zadanie dla locka, albo transakcji.

0

Tak, ale jeśli do API przyjdzie drugie i trzecie zapytanie, to klient tylko czeka na odpowiedź dłużej, jeśli API pierwszego nie skończy. Wolałbym ominąć powtórzenia zapytania. Nie wiem czy dobrze rozumiem kwestie locka. Możesz rozwinąć też kwestie transakcji?

1

Lock zapewni nam że tylko jeden request będzie przetwarzany w danym czasie, natomiast jeśli problem jest współbieżna edycja danych na bazie danych, to dajesz transakcję z poziomem izolacji serializable + for update. A jeśli robisz api w wcf to on już ma tam wbudowany tryb przetwarzania szeregowego (ConcurrencyMode.Single) właśnie oparty na locku.

        private static readonly object lockObject = new object();


        [HttpGet("headers")]
        public ActionResult<IReadOnlyList<TestHeaderDTO>> ReadTestHeaders(long catalogId)
        {
            lock (lockObject)
            {
                var result = service.ReadTestHeaders(UserId, catalogId);

                 return ActionResult(result);
            }
        }
0

Ooo masakrooo! Panie :D
Jak googlowałem swój problem to na siłe wciskałem, że to problem z API i miałem już takie cuda, że jak patrze na to rozwiązanie to aż chce się żyć. Dzięki wielkie ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1