Fehlerbehebung-FAQ

AWS SDK for Java 2.x Bei der Verwendung von in Ihren Anwendungen können die in diesem Thema aufgeführten Laufzeitfehler auftreten. Verwenden Sie die hier aufgeführten Vorschläge, um die Ursache zu ermitteln und den Fehler zu beheben.

Wie behebe ich den Fehler "java.net.SocketException: Verbindung zurückgesetzt“ oder „Server konnte die Antwort nicht abschließen“?

Ein Fehler beim Zurücksetzen der Verbindung weist darauf hin, dass Ihr Host AWS-Service, der oder eine zwischengeschaltete Partei (z. B. ein NAT-Gateway, ein Proxy, ein Load Balancer) die Verbindung geschlossen hat, bevor die Anfrage abgeschlossen war. Da es viele Ursachen gibt, müssen Sie für die Suche nach einer Lösung wissen, warum die Verbindung geschlossen wurde. Die folgenden Faktoren führen in der Regel dazu, dass eine Verbindung geschlossen wird.

• Die Verbindung ist inaktiv.Dies ist bei Streaming-Vorgängen üblich, bei denen für einen bestimmten Zeitraum keine Daten auf oder von der Leitung geschrieben werden, sodass eine zwischengeschaltete Partei die Verbindung als unterbrochen erkennt und sie schließt. Um dies zu verhindern, stellen Sie sicher, dass Ihre Anwendung aktiv Daten herunterlädt oder hochlädt.

• Sie haben den HTTP- oder SDK-Client geschlossen. Achten Sie darauf, Ressourcen nicht zu schließen, während sie verwendet werden.

• Ein falsch konfigurierter Proxy. Versuchen Sie, alle von Ihnen konfigurierten Proxys zu umgehen, um festzustellen, ob das Problem dadurch behoben wird. Wenn das Problem dadurch behoben wird, schließt der Proxy Ihre Verbindung aus irgendeinem Grund. Untersuchen Sie Ihren spezifischen Proxy, um herauszufinden, warum er die Verbindung schließt.

Wenn Sie das Problem nicht identifizieren können, versuchen Sie, einen TCP-Dump für eine betroffene Verbindung am Client-Edge Ihres Netzwerks auszuführen (z. B. hinter allen Proxys, die Sie kontrollieren).

Wenn Sie feststellen, dass der AWS Endpunkt einen TCP RST (Reset) sendet, wenden Sie sich an den betroffenen Dienst, um herauszufinden, warum der Reset durchgeführt wird. Seien Sie bereit, Anfrage-IDs und Zeitstempel anzugeben, wann das Problem aufgetreten ist. Das AWS Support-Team könnte auch von Übertragungsprotokollen profitieren, aus denen genau hervorgeht, welche Byte Ihre Anwendung wann sendet und empfängt.

Wie behebe ich das „Verbindungs-Timeout“?

Ein Verbindungs-Timeout-Fehler weist darauf hin, dass Ihr Host AWS-Service, der oder eine zwischengeschaltete Partei (z. B. ein NAT-Gateway, ein Proxy, ein Load Balancer) innerhalb des konfigurierten Verbindungstimeouts keine neue Verbindung mit dem Server herstellen konnte. In den folgenden Abschnitten werden die häufigsten Ursachen für dieses Problem beschrieben.

• Das konfigurierte Verbindungstimeout ist zu niedrig. Standardmäßig beträgt das Verbindungstimeout 2 Sekunden in der. AWS SDK for Java 2.x Wenn Sie das Verbindungstimeout zu niedrig einstellen, wird möglicherweise dieser Fehler angezeigt. Das empfohlene Verbindungstimeout beträgt 1 Sekunde, wenn Sie nur Anrufe innerhalb der Region tätigen, und 3 Sekunden, wenn Sie regionsübergreifende Anfragen stellen.

• Ein falsch konfigurierter Proxy. Versuchen Sie, alle von Ihnen konfigurierten Proxys zu umgehen, um festzustellen, ob das Problem dadurch behoben wird. Wenn das Problem dadurch behoben wird, ist der Proxy der Grund für das Verbindungstimeout. Recherchiere deinen spezifischen Proxy, um herauszufinden, warum das passiert

Wenn Sie das Problem nicht identifizieren können, versuchen Sie, einen TCP-Dump für eine betroffene Verbindung am Client-Edge Ihres Netzwerks auszuführen (z. B. hinter allen Proxys, die Sie kontrollieren), um das Netzwerkproblem zu untersuchen.

Wie behebe ich "java.net.SocketTimeoutException: Timeout beim Lesen“?

Ein Timeout-Fehler beim Lesen weist darauf hin, dass die JVM versucht hat, Daten vom zugrunde liegenden Betriebssystem zu lesen, die Daten jedoch nicht innerhalb der über das SDK konfigurierten Zeit zurückgegeben wurden. Dieser Fehler kann auftreten, wenn das Betriebssystem AWS-Service, die oder eine zwischengeschaltete Partei (z. B. ein NAT-Gateway, ein Proxy, ein Load Balancer) Daten nicht innerhalb der von der JVM erwarteten Zeit sendet. Da es viele Ursachen gibt, müssen Sie für die Suche nach einer Lösung wissen, warum die Daten nicht zurückgegeben werden.

Versuchen Sie, einen TCP-Dump für eine betroffene Verbindung am Client-Edge Ihres Netzwerks auszuführen (z. B. hinter allen Proxys, die Sie kontrollieren).

Wenn Sie feststellen, dass der AWS Endpunkt einen TCP RST (Reset) sendet, wenden Sie sich an den betroffenen Dienst. Seien Sie bereit, Anfrage-IDs und Zeitstempel anzugeben, wann das Problem aufgetreten ist. Das AWS Support-Team könnte auch von Übertragungsprotokollen profitieren, aus denen genau hervorgeht, welche Byte Ihre Anwendung wann sendet und empfängt.

Wie behebe ich den Fehler „HTTP-Anfrage kann nicht ausgeführt werden: Timeout beim Warten auf Verbindung vom Pool“?

Dieser Fehler weist darauf hin, dass eine Anfrage innerhalb der angegebenen maximalen Zeit keine Verbindung vom Pool herstellen kann. Um das Problem zu beheben, empfehlen wir, die clientseitigen SDK-Metriken zu aktivieren, um Metriken auf Amazon zu veröffentlichen. CloudWatch Die HTTP-Metriken können helfen, die Ursache einzugrenzen. In den folgenden Artikeln werden die häufigsten Ursachen für diesen Fehler beschrieben.

• Verbindungsleck. Sie können dies untersuchen, indem Sie die MaxConcurrency Metriken LeasedConcurrencyAvailableConcurrency,, und überprüfen. Wenn der Wert LeasedConcurrency zunimmt, bis er den Wert erreicht, MaxConcurrency aber nie abnimmt, liegt möglicherweise ein Verbindungsleck vor. Eine häufige Ursache für ein Datenleck ist, dass ein Streaming-Vorgang — z. B. eine getObject S3-Methode — nicht abgeschlossen ist. Wir empfehlen, dass Ihre Anwendung so schnell wie möglich alle Daten aus dem Eingabestream liest und den Eingabestream anschließend schließt. Die folgende Tabelle zeigt, wie SDK-Metriken für Verbindungslecks aussehen könnten.

  

• Mangel an Verbindungspool.Dies kann passieren, wenn Ihre Anforderungsrate zu hoch ist und die konfigurierte Größe des Verbindungspools den Anforderungsbedarf nicht decken kann. Die Standardgröße des Verbindungspools ist 50, und wenn die Verbindungen im Pool das Maximum erreichen, stellt der HTTP-Client eingehende Anfragen in eine Warteschlange, bis Verbindungen verfügbar sind. Die folgende Tabelle zeigt, wie SDK-Metriken bei einem Ausfall des Verbindungspools aussehen könnten.

  

  Um dieses Problem zu beheben, sollten Sie eine der folgenden Maßnahmen in Betracht ziehen.

  • Erhöhen Sie die Größe des Verbindungspools,

  • Erhöhen Sie das Zeitlimit für die Erfassung.

  • Verlangsamen Sie die Anforderungsrate.

  Durch die Erhöhung der maximalen Anzahl von Verbindungen kann der Client-Durchsatz erhöht werden (sofern die Netzwerkschnittstelle nicht bereits voll ausgelastet ist). Im Laufe der Zeit kann es jedoch zu Einschränkungen des Betriebssystems kommen, was die Anzahl der vom Prozess verwendeten Dateideskriptoren angeht. Wenn Sie Ihre Netzwerkschnittstelle bereits vollständig nutzen oder die Anzahl der Verbindungen nicht weiter erhöhen können, versuchen Sie, das Acque-Timeout zu erhöhen. Mit der Erhöhung gewinnen Sie zusätzliche Zeit für Anfragen zum Verbindungsaufbau, bevor das Timeout abläuft. Wenn die Verbindungen nicht freigegeben werden, kommt es bei den nachfolgenden Anfragen trotzdem zu einem Timeout.

  Wenn Sie das Problem mit den ersten beiden Mechanismen nicht beheben können, verringern Sie die Anforderungsrate, indem Sie die folgenden Optionen ausprobieren.

  • Glätten Sie Ihre Anfragen, sodass der Client nicht durch große Datenströme überlastet wird.

  • Seien Sie effizienter mit Anrufen an AWS-Services.

  • Erhöhen Sie die Anzahl der Hosts, die Anfragen senden.

• I/O-Threads sind zu ausgelastet. Dies gilt nur, wenn Sie einen asynchronen SDK-Client mit NettyNioAsyncHttpClientverwenden. Wenn die AvailableConcurrency Metrik nicht niedrig ist — was darauf hinweist, dass Verbindungen im Pool verfügbar sind —, sondern hoch, ConcurrencyAcquireDuration liegt das möglicherweise daran, dass I/O-Threads die Anfragen nicht verarbeiten können. Stellen Sie sicher, dass Sie sich nicht Runnable:run als Future Completion Executor ausgeben und zeitaufwändige Aufgaben in der Antwort-Future-Completion-Kette ausführen, da dies einen I/O-Thread blockieren kann. Wenn das nicht der Fall ist, sollten Sie erwägen, die Anzahl der I/O-Threads mithilfe der eventLoopGroupBuilder Methode zu erhöhen. Als Referenz: Die Standardanzahl von I/O-Threads für eine NettyNioAsyncHttpClient Instanz ist doppelt so hoch wie die Anzahl der CPU-Kerne des Hosts.

• Hohe TLS-Handshake-Latenz. Wenn Ihre AvailableConcurrency Metrik nahe 0 und niedriger als LeasedConcurrency ist, kann dies daran liegenMaxConcurrency, dass die TLS-Handshake-Latenz hoch ist. Die folgende Tabelle zeigt, wie SDK-Metriken für eine hohe TLS-Handshake-Latenz aussehen könnten.

  

  Versuchen Sie für vom Java SDK angebotene HTTP-Clients, die nicht auf CRT basieren, TLS-Protokolle zu aktivieren, um TLS-Probleme zu beheben. Versuchen Sie für den AWS CRT-basierten HTTP-Client, CRT-Protokolle zu aktivieren AWS . Wenn Sie feststellen, dass der AWS Endpunkt anscheinend lange braucht, um einen TLS-Handshake durchzuführen, sollten Sie sich an den betroffenen Dienst wenden.

Wie behebe ich einNoClassDefFoundError, NoSuchMethodError oderNoSuchFieldError?

A NoClassDefFoundError gibt an, dass eine Klasse zur Laufzeit nicht geladen werden konnte. Die zwei häufigsten Ursachen für diesen Fehler sind:

• Die Klasse ist im Klassenpfad nicht vorhanden, weil die JAR fehlt oder die falsche Version der JAR sich im Klassenpfad befindet.

• Die Klasse konnte nicht geladen werden, weil ihr statischer Initialisierer eine Ausnahme ausgelöst hat.

In ähnlicher Weise resultieren NoSuchMethodError s und NoSuchFieldError s typischerweise aus einer nicht übereinstimmenden JAR-Version. Wir empfehlen Ihnen, die folgenden Schritte durchzuführen.

1. Überprüfen Sie Ihre Abhängigkeiten, um sicherzustellen, dass Sie dieselbe Version aller SDK-Jars verwenden. Der häufigste Grund dafür, dass eine Klasse, Methode oder ein Feld nicht gefunden werden kann, ist, wenn Sie auf eine neue Client-Version aktualisieren, aber weiterhin eine alte, gemeinsam genutzte SDK-Abhängigkeitsversion verwenden. Die neue Client-Version versucht möglicherweise, Klassen zu verwenden, die nur in neueren „gemeinsam genutzten“ SDK-Abhängigkeiten existieren. Versuchen Sie, mvn dependency:tree oder gradle dependencies (für Gradle) auszuführen, um zu überprüfen, ob alle Versionen der SDK-Bibliothek übereinstimmen. Um dieses Problem in future vollständig zu vermeiden, empfehlen wir die Verwendung von BOM (Bill of Materials) zur Verwaltung von SDK-Modulversionen.

   Das folgende Beispiel zeigt Ihnen ein Beispiel für gemischte SDK-Versionen.

   [INFO] +- software.amazon.awssdk:dynamodb:jar:2.20.00:compile
   [INFO] |  +- software.amazon.awssdk:aws-core:jar:2.13.19:compile
   [INFO] +- software.amazon.awssdk:netty-nio-client:jar:2.20.00:compile

   Die Version von dynamodb ist 2.20.00 und die Version von aws-core ist 2.13.19. Die aws-core Artefaktversion sollte ebenfalls 2.20.00 sein.

2. Überprüfen Sie die Anweisungen zu Beginn Ihrer Logs, um festzustellen, ob eine Klasse aufgrund eines statischen Initialisierungsfehlers nicht geladen werden kann. Wenn die Klasse zum ersten Mal nicht geladen werden kann, wird möglicherweise eine andere, nützlichere Ausnahme ausgelöst, die angibt, warum die Klasse nicht geladen werden kann. Diese potenziell nützliche Ausnahme tritt nur einmal auf, sodass spätere Protokollanweisungen nur melden, dass die Klasse nicht gefunden wurde.

3. Überprüfen Sie Ihren Bereitstellungsprozess, um sicherzustellen, dass die erforderlichen JAR-Dateien tatsächlich zusammen mit Ihrer Anwendung bereitgestellt werden. Es ist möglich, dass Sie mit der richtigen Version bauen, aber der Prozess, der den Klassenpfad für Ihre Anwendung erstellt, schließt eine erforderliche Abhängigkeit aus.

Wie behebe ich den Fehler "SignatureDoesNotMatch" oder den Fehler „Die von uns berechnete Anforderungssignatur stimmt nicht mit der von Ihnen angegebenen Signatur überein“?

Ein SignatureDoesNotMatch Fehler weist darauf hin, dass die von generierte Signatur AWS SDK for Java und die von der generierte Signatur AWS-Service nicht übereinstimmen. In den folgenden Punkten werden mögliche Ursachen beschrieben.

• Ein Proxy oder eine zwischengeschaltete Partei ändert die Anfrage. Beispielsweise könnte ein Proxy oder Load Balancer einen Header, Pfad oder eine Abfragezeichenfolge ändern, die vom SDK signiert wurden.

• Der Dienst und das SDK unterscheiden sich darin, wie sie die Anfrage codieren, wenn sie jeweils die zu signierende Zeichenfolge generieren.

Um dieses Problem zu beheben, empfehlen wir, die Debug-Protokollierung für das SDK zu aktivieren. Versuchen Sie, den Fehler zu reproduzieren und die kanonische Anfrage zu finden, die das SDK generiert hat. Im Protokoll ist die kanonische Anfrage mit AWS4 Canonical Request: ... und die zu signierende Zeichenfolge gekennzeichnet. AWS4 String to sign: ...

Wenn Sie das Debuggen nicht aktivieren können, z. B. weil es nur in der Produktion reproduzierbar ist, fügen Sie Ihrer Anwendung eine Logik hinzu, die Informationen über die Anfrage protokolliert, wenn der Fehler auftritt. Sie können diese Informationen dann verwenden, um zu versuchen, den Fehler außerhalb der Produktion in einem Integrationstest mit aktivierter Debug-Protokollierung zu replizieren.

Nachdem Sie die kanonische Anfrage und die zu signierende Zeichenfolge erfasst haben, vergleichen Sie sie mit der AWS Signature Version 4-Spezifikation, um festzustellen, ob es Probleme mit der Art und Weise gibt, wie das SDK die zu signierende Zeichenfolge generiert hat. Wenn etwas nicht in Ordnung zu sein scheint, können Sie einen GitHub Fehlerbericht an die erstellen. AWS SDK for Java

Wenn nichts falsch zu sein scheint, können Sie die Zeichenkette zum Signieren des SDK mit der Zeichenfolge vergleichen, die einige als Teil der Fehlerreaktion AWS-Services zurückgeben (z. B. Amazon S3). Wenn dies nicht verfügbar ist, sollten Sie sich an den betroffenen Dienst wenden, um zu erfahren, welche kanonische Anfrage und welche Zeichenfolge zum Signieren er für den Vergleich generiert hat. Diese Vergleiche können helfen, zwischengeschaltete Parteien zu identifizieren, die möglicherweise die Anfrage oder die Codierungsunterschiede zwischen dem Dienst und dem Client geändert haben.

Weitere Hintergrundinformationen zum Signieren von Anfragen finden Sie im AWS Identity and Access Management Benutzerhandbuch unter Signieren von AWS API-Anfragen.

Beispiel einer kanonischen Anfrage

PUT
/Example-Bucket/Example-Object
partNumber=19&uploadId=string
amz-sdk-invocation-id:f8c2799d-367c-f024-e8fa-6ad6d0a1afb9
amz-sdk-request:attempt=1; max=4
content-encoding:aws-chunked
content-length:51
content-type:application/octet-stream
host:xxxxx
x-amz-content-sha256:STREAMING-UNSIGNED-PAYLOAD-TRAILER
x-amz-date:20240308T034733Z
x-amz-decoded-content-length:10
x-amz-sdk-checksum-algorithm:CRC32
x-amz-trailer:x-amz-checksum-crc32

Beispiel einer zu signierenden Zeichenfolge

AWS4-HMAC-SHA256
20240308T034435Z
20240308/us-east-1/s3/aws4_request
5f20a7604b1ef65dd89c333fd66736fdef9578d11a4f5d22d289597c387dc713

Wie behebe ich den Fehler "java.lang.IllegalStateException: Der Verbindungspool wurde heruntergefahren“?

Dieser Fehler weist darauf hin, dass der zugrunde liegende Apache HTTP-Verbindungspool geschlossen wurde. In den folgenden Artikeln werden mögliche Ursachen beschrieben.

• Der SDK-Client wurde vorzeitig geschlossen.Das SDK schließt den Verbindungspool nur, wenn der zugehörige Client geschlossen wird. Achten Sie darauf, Ressourcen nicht zu schließen, während sie verwendet werden.

• A java.lang.Error wurde geworfen. Fehler, die z. B. OutOfMemoryError dazu führen, dass ein Apache HTTP-Verbindungspool heruntergefahren wird. Untersuchen Sie Ihre Logs auf Fehler-Stack-Traces. Überprüfen Sie Ihren Code auch auf Stellen, an denen er Throwable s oder Error s abfängt, aber die Ausgabe verschluckt, wodurch verhindert wird, dass der Fehler auftaucht. Wenn Ihr Code keine Fehler meldet, schreiben Sie den Code neu, sodass die Informationen protokolliert werden. Die protokollierten Informationen helfen dabei, die Ursache des Fehlers zu ermitteln.

• Sie haben versucht, den Anbieter für Anmeldeinformationen zu verwenden, der DefaultCredentialsProvider#create() nach dem Schließen zurückgegeben wurde. DefaultCredentialsProvider#creategibt eine Singleton-Instanz zurück. Wenn sie also geschlossen ist und Ihr Code die resolveCredentials Methode aufruft, wird die Ausnahme ausgelöst, nachdem die zwischengespeicherten Anmeldeinformationen (oder Token) abgelaufen sind.

  Überprüfen Sie Ihren Code auf Stellen, an denen der geschlossen DefaultCredentialsProvider ist, wie in den folgenden Beispielen gezeigt.

  • Die Singleton-Instanz wird durch Aufrufen geschlossen DefaultCredentialsProvider#close().

    DefaultCredentialsProvider defaultCredentialsProvider = DefaultCredentialsProvider.create(); // Singleton instance returned.
    AwsCredentials credentials = defaultCredentialsProvider.resolveCredentials();
    
    // Make calls to AWS-Services.
    
    defaultCredentialsProvider.close();  // Explicit close.
    
    // Make calls to AWS-Services.
    
    // After the credentials expire, either of the following calls eventually results in a "Connection pool shut down" exception.
    credentials = defaultCredentialsProvider.resolveCredentials();
    // Or
    credentials = DefaultCredentialsProvider.create().resolveCredentials();

  • DefaultCredentialsProvider#create()In einem try-with-resources Block aufrufen.

    try (DefaultCredentialsProvider defaultCredentialsProvider = DefaultCredentialsProvider.create()) {
        AwsCredentials credentials = defaultCredentialsProvider.resolveCredentials();
        
        // Make calls to AWS-Services.
    
    } // After the try-with-resources block exits, the singleton DefaultCredentialsProvider is closed.
    
    // Make calls to AWS-Services.
    
    DefaultCredentialsProvider defaultCredentialsProvider = DefaultCredentialsProvider.create(); // The closed singleton instance is returned.
    // If the credentials (or token) has expired, the following call results in the error.
    AwsCredentials credentials = defaultCredentialsProvider.resolveCredentials();

  Erstellen Sie eine neue Nicht-Singleton-Instanz, indem Sie aufrufen, DefaultCredentialsProvider.builder().build() falls Ihr Code die Singleton-Instanz geschlossen hat und Sie Anmeldeinformationen mithilfe von a auflösen müssen. DefaultCredentialsProvider