API Aufruf besser steuern, wie Fehler vermeiden

[OnDemand]

Hallo Zusammen,

ich habe ein paar API angebunden bekomme aber dummerweise von so ziemlich allen immer mal wieder 500er oder I/O Error. Verbindungen werden zurückgewiesen, Server überlastet usw. Dabei sende ich nur kleine json Strings zum Server.

Es sind verschiedene Provider auf die ich keinen Einfluss habe, wäre es sinnvoll nach jedem Aufruf Thead.sleep für 5 Millisekunden aufzurufen, dass der Server gegenüber nicht überlastet? Ist ziemlich ätzend.

Server/Hosting aufstocken ist leider keine Option

 

[mihe7]

Von welcher Seite sprichst Du jetzt? Client oder Server?

 

[LimDul]

Und wie oft rufst du die auf?

 

[kneitzel]

Also einige kommerzielle APIs schützen sich gegen zu viele Aufrufe. Amazon ist da ein gutes Beispiel und da haben die Webservice calls in der Doku sogar klare Hinweise, wie oft diese aufgerufen werden dürfen.

Daher ist der Anbieter diesbezüglich zu prüfen. Und ob da ein kleiner sleep ausreicht hängt klar von Anbieter ab.

Von der Amazon API für Verkäufer (einfach mal als Beispiel) ist es teilweise so, dass da bis zu 5 Sekunden zwischen zwei Aufrufen sein müssen (Produktsuche um ASIN zu bekommen), andere Aufrufe sind 1 oder 2 Mal pro Sekunde erlaubt ...

 

[OnDemand]

Ich als Client bekomme die Fehlermeldung vom der fremden API Serverumgebung. Solch eine Begrenzung gibt es nicht, kommt iwie aus dem Netzwerk oder Überlastungen. Aufgerufen wird ca jede Sekunde ein Update, nicht mal mehrere parallel. Bei einem Anbieter schicke ich 10k Updates hin, da läuft es durch, bei anderen muss ich immer und immer wieder beginnen. (Batchupdate nicht möglich)

 

[LimDul]

Dann bleibt dir nix übrig als
* Entweder beim Betreiber der API drauf drängen, dass die stabilere Systeme bereitstellen
* Beim Aufruf prüfen, ob er durchgeht und wenn nicht nach X Millisekunden es nochmal probieren.

Bist du 100% Sicher das es keine Begrenzung gibt?

 

[OnDemand]

Grad eben wieder :/
I/O error on POST request for "https://xxx": Unexpected end of file from server; nested exception is java.net.SocketException: Unexpected end of file from server

 

[OnDemand]

Bist du 100% Sicher das es keine Begrenzung gibt?

von der installierten Software gibt es keine Begrenzung, hab ich schon angefragt. Dann würde da auch irgendwas kommen wie "zu viele Aufrufe Blabla" so ist es auch bei Amazon wenn ich bei deinem Beispiel bleibe.

 

[OnDemand]

Mir kam grad noch eine Idee, dass die evtl Fail2Ban installiert haben, dass hat Plesk zb von haus aus im Hosting mein ich. Das reagiert ziemlich schnell wenn da eine IP permanent auf was zugreift.

 

[mrBrown]

Verhindert wirst du das nie gänzlich können, je nachdem was du selbst nutzt gibts aber zumindest Hilfe: Microprofile Fault Tolerance oder zB resilience4j oder Hystrix

 

[kneitzel]

Also bei Fail2Ban müsste in der Regel ein Failure im Logfile auftauchen. Und dann kommt gar kein Connect mehr durch, d.h. Deine Anfragen laufen alle gnadenlos auf einen Timeout schon beim Connect. Ebenso bei der Abwehr von DOS Angriffen.

 

[OnDemand]

Also bei Fail2Ban müsste in der Regel ein Failure im Logfile auftauchen. Und dann kommt gar kein Connect mehr durch, d.h. Deine Anfragen laufen alle gnadenlos auf einen Timeout schon beim Connect. Ebenso bei der Abwehr von DOS Angriffen.

Hast Recht, fiel mir in der Nacht auch ein, der würde dann komplett blocken.

@mrBrown das liest sich ja auf den ersten Blick super. Ich nutze spring Boot, muss ich ich mir später unbedingt genauer ansehen. Der Gegenpart ist allerdings nicht Spring, das ist was PHP

 

[mrBrown]

Der Gegenpart ist allerdings nicht Spring, das ist was PHP

Der Gegenpart ist egal, das nutzt man auf Consumer-Seite

 

[OnDemand]

Super, was würdest du empfehlen von den dreien? Hystrix scheint mir aufwendiger

 

[mrBrown]

Mit Spring Boot dürfte aktuell das am besten klappen: https://github.com/resilience4j/resilience4j-spring-boot2-demo

 

[OnDemand]

wirklich? 😵 sieht mir am weit entferntesten von einfach aus

 

[mrBrown]

Öhm, das ist zB der Code zum mehrmals versuchen:

@Retry(name = "IrgendeinNameFürDenService")
public Objekt tueIrgendwas() {...}

Was hast du dir denn angeguckt?[/code]

 

[thecain]

Mit Spring Boot dürfte aktuell das am besten klappen

Ist nicht Hystrix der "default" Circuit breaker bei SpringBoot?

 

[mrBrown]

Ist nicht Hystrix der "default" Circuit breaker bei SpringBoot?

Kann gut sein, allerdings wird Hystrix ja nicht mehr geupdated und resilenence4j empfohlen

 

[thecain]

Hast Recht. Habe auch gerade nachgelesen. Hystrix unterstützt zwar Fallbacks, aber kein Retry

 

[OnDemand]

Bekomm es nichts ins Projekt. folgenden Eintrag in die POM hab ich gemacht:

aber @EnableRetry wird nicht erkannt, meckert ItelliJ. Hab es auf der Startklasse annotiert

  <!-- https://mvnrepository.com/artifact/io.github.resilience4j/resilience4j-retry -->
        <dependency>
            <groupId>io.github.resilience4j</groupId>
            <artifactId>resilience4j-retry</artifactId>
            <version>1.4.0</version>
        </dependency>
        <!-- https://mvnrepository.com/artifact/io.github.resilience4j/resilience4j-circuitbreaker -->
        <dependency>
            <groupId>io.github.resilience4j</groupId>
            <artifactId>resilience4j-circuitbreaker</artifactId>
            <version>1.4.0</version>
        </dependency>

EDIT: IntelliJCache war schuld