Results 1 to 6 of 6

Thread: API Request met result 12002 timeout toch correct uitgevoerd: hoe te controleren?

  1. #1
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,861

    API Request met result 12002 timeout toch correct uitgevoerd: hoe te controleren?

    Hi

    In een applicatie worden requests gedaan naar een API. Eén van die requests duurt altijd wat langer maar duurde onlangs langer dan normaal met als gevolg een exception "12002" timeout. Achteraf bleek het request toch goed uit te zijn gevoerd met een juiste statuscode, alleen dus niet binnen de default tijdlimiet.

    Oplossing is de timeout verhogen, maar wanneer is deze hoog genoeg? Dat blijft een gok.

    Vraag: kan je na het ontvangen van een exception timeout in een loop alsnog een statuscode terugkrijgen totdat deze een gewenste code teruggeeft? bijv:

    Code:
    var
      i, j: integer;
    begin
      i := 0;
      try
        RESTRequest.Execute;
      except
        on E:ERESTException do
        begin
          if AnsiContainsText( E.Message, '(12002)' ) then
          begin
            for i := 0 to 10 do  // maximaal 10 pogingen om de statuscode op te vragen na een timeout
            begin
              if RESTRequest.Response.StatusCode  = 0 then
              begin
                for j := 0 to 10 do    // 10 seconden wachten voordat we opnieuw de statuscode opvragen
                  sleep(1000);
              end
              else
                break;
            end;
          end
        end;
      end;
    end;
    Last edited by Hans Brenkman; 06-Sep-22 at 16:22.
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  2. #2
    Wat schiet je daarmee op?
    Waarom dan niet gewoon de timeout verhogen?
    Als je antwoord krijgt keert de routine ook gelijk terug.
    Dus die timeout gewoon met 10 seconden verhogen heeft hetzelfde effect.

    Ps. Ik verwacht dat je na de exception geen result meer binnenkrijgt (ondanks dat de server hem nog wel verstuurd) dus de loop zou niet eens een oplossing zijn.

  3. #3
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,861
    De timeout verhogen is het eerste wat ik nu heb gedaan. Maar als 30 seconden (default) niet genoeg is, is misschien 60 seconden ook niet genoeg.

    Vandaar mijn vraag om alsnog te wachten op een statuscode waar je dan vervolgens ook echt iets uit kan afleiden. Maar als die timeout hoog genoeg is, moet de statuscode uiteindelijk wel komen.
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  4. #4
    Oplossing is de timeout verhogen, maar wanneer is deze hoog genoeg? Dat blijft een gok.
    Je kunt je misschien beter leren "gokken", door de timeout heel erg hoog te zetten te kijken wat de response tijden zijn en wat een acceptabele timeout is voor dat specifieke request. Het blijft natuurlijk arbitrair.

    kan je na het ontvangen van een exception timeout in een loop alsnog een statuscode terugkrijgen totdat deze een gewenste code teruggeeft?
    Volgens mij niet.

  5. #5
    Quote Originally Posted by Hans Brenkman View Post
    De timeout verhogen is het eerste wat ik nu heb gedaan. Maar als 30 seconden (default) niet genoeg is, is misschien 60 seconden ook niet genoeg.
    Je moet niet kijken naar welke timeout je verwacht, je moet kijken naar welke timeout je acceptabel vindt.

    Als jij 120 seconden geen probleem vindt dan zet je hem op 120.
    Als je denkt dat het 600 seconden is, zet je hem op 600 seconden.
    Voor de gevallen waarin de server eerder reageert is dat allemaal niet erg.

  6. #6
    Je kan de call eventueel doen in een thread. Dan kan je wellicht wat makkelijker de timeout verhogen zonder dat je gebruiker er direct last van heeft, al moet je applicatie dan wel om kunnen gaan met het feit dat die call nog loopt op de achtergrond, en op een bepaald moment alsnog een timeout of bepaald resultaat gaat geven.
    1+1=b

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •