API Aufruf besser steuern, wie Fehler vermeiden

NicoDeluxe

NicoDeluxe

Top Contributor
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
 
kneitzel

kneitzel

Top Contributor
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 ...
 
NicoDeluxe

NicoDeluxe

Top Contributor
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)
 
L

LimDul

Top Contributor
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?
 
NicoDeluxe

NicoDeluxe

Top Contributor
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
 
NicoDeluxe

NicoDeluxe

Top Contributor
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.
 
kneitzel

kneitzel

Top Contributor
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.
 
NicoDeluxe

NicoDeluxe

Top Contributor
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

mrBrown

Super-Moderator
Mitarbeiter
Öhm, das ist zB der Code zum mehrmals versuchen:
Java:
@Retry(name = "IrgendeinNameFürDenService")
public Objekt tueIrgendwas() {...}

Was hast du dir denn angeguckt?[/code]
 
Zuletzt bearbeitet:
NicoDeluxe

NicoDeluxe

Top Contributor
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

Code:
  <!-- 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
 
Zuletzt bearbeitet:

Ähnliche Java Themen


Oben