Jak zwiększyć domyślny timeout na więcej niż 100 sekund?

0

Od 2 godzin próbuję zwiększyć timeout z domyślnych 100 sekund na większy. Mam endpoint, który musi przetworzyć troszkę więcej danych z bazy do tabelki.
Próbowałem dodać, UseKestrel jednak to niepomaga

private static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
  WebHost.CreateDefaultBuilder(args)
      .UseStartup<Startup>()
      .UseKestrel(x =>
      {
          x.Limits.KeepAliveTimeout = TimeSpan.FromMinutes(10);
      });
}

Chcę to zrobić dla dwóch endpointów, jednak za każdym razem leci ten błąd.

Przykładowy endponit:

[HttpPost]
[Route("reports/rides")]
public async Task<IActionResult> GetRides([FromBody] RidesReportQuery command)
{
    return ToHttpResult(await _mediator.Send(command, CancellationToken.None));
}

Wcześniej miałem HttpContext.RequestAborted zmieniłem na CancellationToken.None.
Próbowałem również

[HttpPost]
[Route("reports/rides")]
public async Task<IActionResult> GetRides([FromBody] RidesReportQuery command)
{
    using var cts = new CancellationTokenSource(TimeSpan.FromMinutes(10));
    return ToHttpResult(await _mediator.Send(command, cts.Token));
}

Istnieje jakiś prosty sposób na zmianę timeout? Widzę, że w .net 8 jest odpowiedni atrybut już.

1
Michalk001 napisał(a):

Chcę to zrobić dla dwóch endpointów, jednak za każdym razem leci ten błąd.

Ten błąd, czyli jaki? ;)

3

Jesteś pewien że zwiększenie timeout'u to dobry pomysł?

Czemu nie zrobić dwóch endpointów, jednego POST który uruchamia kosztowne operacje w kolejce lub background workerze, i drugi GET którym możesz odczytać aktualny status/wynik?

0

Z tego co wiem to w .NET < 8 nie da się. Zrób jak pisze @Riddle i nie kombinuj.

P.S. swoją drogą czemu instancja obiektu typu Query w twoim kodzie nazywa się command? :P

0

@some_ONE: Błąd z przekroczeniem timeout
@Riddle: Raporty są w workerze generowanie, jednak tutaj jest problem, bo jest tabelka na frontach, do której dane spływają na bieżąco i można wybrać zakres, więc nie mogę tego wygenerować tak jak napisałeś. Na bazie jest parenaście milionów wpisów i potrzebuje więcej czasu niż 100 sekund, kiedy wybierze się większy zakres. Np. od początku roku. Dla zakresu rzędu dwóch, trzech miesięcy miesięcy jest ok. Na podstawie tej tabelki można wyeksportować również dane do excela.
@markone_dev: Nie wiem, nie mnie o to pytać.

1
Michalk001 napisał(a):

@Riddle: Raporty są w workerze generowanie, jednak tutaj jest problem, bo jest tabelka na frontach, do której dane spływają na bieŻąco (Boże, widzisz takie błędy i nie grzmisz) i można wybrać zakres, więc nie mogę tego wygenerować tak jak napisałeś. Na bazie jest parenaście milionów wpisów i potrzebuje więcej czasu niż 100 sekund, kiedy wybierze się większy zakres. Np. od początku roku. Dla zakresu rzędu dwóch, trzech miesięcy miesięcy jest ok. Na podstawie tej tabelki można wyeksportować również dane do excela.

No i co to przeszkadza? Skoro chcesz zwiększyć timeout na więcej niż 100 sekund, to i tak user experience jest taki:

  1. Użytkownik widzi dużą tabelkę
  2. Użytkownik zmienia zakres
  3. Użytkownik czeka dłużej niż 100 sekund
  4. Użytkownik widzi dane ze swojego adresu

Więc to mogłoby się stać tak:

  1. Użytkownik widzi dużą tabelkę
  2. Użytkownik zmienia zakres
  3. Klient robi POST z prośbą o wygenerowanie zakresu danych które trwa 100 sekund +
  4. Background worker zaczyna mielić
  5. Użytkownik czeka dłużej niż 100 sekund
  6. Klient robi GET z prośbą o wczytanie danych
  7. Użytkownik widzi dane ze swojego adresu

Po prostu przenieś "pracę" fetchowania tych raportów z endpointu do background workera.

0
Michalk001 napisał(a):

@markone_dev: Nie wiem, nie mnie o to pytać.

Rozumiem. Niemniej zasada skauta przy pracy z zastanym kodem to dobra zasada.

0

Chciałbym, ale budżet nie pozwala na takie zmiany, a tutaj chodzi o jednostkowy przypadek, aby nie musieć właśnie pisać takiego raportu.

0

Ten timeout chyba ustawiasz dla samego HttpClienta. Jeśli masz named clienta lub typed clienta to w factory ustaw mu timeout.

https://learn.microsoft.com/pl-pl/dotnet/api/system.net.http.httpclient.timeout?view=net-7.0

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