Domande frequenti per la soluzione dei problemi

Durante l'utilizzo di AWS SDK for Java 2.x nelle applicazioni, è possibile che si verifichino gli errori di runtime elencati in questo argomento. Utilizzate i suggerimenti riportati di seguito per individuare la causa principale e risolvere l'errore.

Come posso correggere l'errore "java.net.SocketException: ripristino della connessione» o «il server non è riuscito a completare la risposta»?

Un errore di reimpostazione della connessione indica che l'host Servizio AWS, l'intermediario (ad esempio un gateway NAT, un proxy, un sistema di bilanciamento del carico) ha chiuso la connessione prima del completamento della richiesta. Poiché le cause sono molteplici, per trovare una soluzione è necessario conoscere il motivo per cui la connessione viene chiusa. I seguenti elementi causano in genere la chiusura di una connessione.

• La connessione non è attiva.Ciò è comune nelle operazioni di streaming, in cui i dati non vengono scritti sul cavo o dal cavo per un certo periodo di tempo, quindi una parte intermediaria rileva che la connessione è interrotta e la chiude. Per evitare che ciò accada, assicurati che l'applicazione scarichi o carichi attivamente i dati.

• Hai chiuso il client HTTP o SDK. Assicurati di non chiudere le risorse mentre sono in uso.

• Un proxy configurato in modo errato. Prova a bypassare tutti i proxy che hai configurato per vedere se il problema viene risolto. Se questo risolve il problema, il proxy sta chiudendo la connessione per qualche motivo. Cerca il tuo proxy specifico per determinare il motivo per cui sta chiudendo la connessione.

Se non riesci a identificare il problema, prova a eseguire un dump TCP per una connessione interessata sul lato client della rete (ad esempio, dopo tutti i proxy che controlli).

Se vedi che l' AWS endpoint sta inviando un TCP RST (ripristino), contatta il servizio interessato per vedere se è in grado di determinare il motivo del ripristino. Preparati a fornire gli ID delle richieste e gli orari in cui si è verificato il problema. Il team di AWS supporto potrebbe anche trarre vantaggio dai registri telefonici che mostrano esattamente quali byte l'applicazione invia e riceve e quando.

Come posso correggere il «timeout della connessione»?

Un errore di timeout della connessione indica che l'host Servizio AWS, il server o qualsiasi intermediario (ad esempio un gateway NAT, un proxy, un sistema di bilanciamento del carico) non è riuscito a stabilire una nuova connessione con il server entro il timeout di connessione configurato. I seguenti elementi descrivono le cause più comuni di questo problema.

• Il timeout di connessione configurato è troppo basso. Per impostazione predefinita, il timeout della connessione è di 2 secondi in. AWS SDK for Java 2.x Se il timeout di connessione è impostato su un valore troppo basso, è possibile che venga visualizzato questo errore. Il timeout di connessione consigliato è di 1 secondo se si effettuano solo chiamate interregionali e di 3 secondi se si effettuano richieste interregionali.

• Un proxy non configurato correttamente. Prova a bypassare tutti i proxy che hai configurato per vedere se il problema viene risolto. Se questo risolve il problema, il motivo del timeout della connessione è il proxy. Cerca il tuo proxy specifico per determinare il motivo per cui ciò sta accadendo

Se non riesci a identificare il problema, prova a eseguire un dump TCP per una connessione interessata sul lato client della rete (ad esempio, dopo tutti i proxy che controlli) per esaminare eventuali problemi di rete.

Come posso risolvere il problema "java.net.SocketTimeoutException: Read timeout»?

Un errore di timeout di lettura indica che la JVM ha tentato di leggere i dati dal sistema operativo sottostante, ma i dati non sono stati restituiti entro il tempo configurato tramite l'SDK. Questo errore può verificarsi se il sistema operativo, la o qualsiasi parte intermediaria (ad esempio Servizio AWS, un gateway NAT, un proxy, un sistema di bilanciamento del carico) non riesce a inviare i dati entro il tempo previsto dalla JVM. Poiché le cause sono molteplici, per trovare una soluzione è necessario conoscere il motivo per cui i dati non vengono restituiti.

Prova a eseguire un dump TCP per una connessione interessata nella periferia client della rete (ad esempio, dopo tutti i proxy che controlli).

Se vedi che l' AWS endpoint sta inviando un TCP RST (reset), contatta il servizio interessato. Preparati a fornire gli ID delle richieste e gli orari in cui si è verificato il problema. Il team di AWS supporto potrebbe anche trarre vantaggio dai registri telefonici che mostrano esattamente quali byte l'applicazione invia e riceve e quando.

Come posso correggere l'errore «Impossibile eseguire la richiesta HTTP: timeout in attesa di connessione dal pool»?

Questo errore indica che una richiesta non può ottenere una connessione dal pool entro il tempo massimo specificato. Per risolvere il problema, ti consigliamo di abilitare i parametri SDK lato client per pubblicare i parametri su Amazon. CloudWatch Le metriche HTTP possono aiutare a restringere la causa principale. I seguenti elementi descrivono le cause più comuni di questo errore.

• Perdita di connessione. Puoi indagare su questo problema controllando LeasedConcurrencyAvailableConcurrency, e MaxConcurrency metriche. Se LeasedConcurrency aumenta fino a raggiungere l'MaxConcurrencyobiettivo ma non diminuisce mai, potrebbe esserci una perdita di connessione. Una causa comune di una perdita di dati è che un'operazione di streaming, ad esempio un metodo S3, non viene chiusa. getObject Consigliamo all'applicazione di leggere tutti i dati dal flusso di input il prima possibile e di chiudere il flusso di input in seguito. La tabella seguente mostra come potrebbero apparire le metriche SDK per le perdite di connessione.

  

• Interruzione del pool di connessioni.Ciò può verificarsi se la frequenza delle richieste è troppo elevata e la dimensione del pool di connessioni configurato non è in grado di soddisfare la richiesta. La dimensione predefinita del pool di connessioni è 50 e quando le connessioni nel pool raggiungono il massimo, il client HTTP mette in coda le richieste in arrivo finché le connessioni non diventano disponibili. Il grafico seguente mostra come potrebbero apparire le metriche SDK in caso di carenza di pool di connessioni.

  

  Per mitigare questo problema, prendi in considerazione l'idea di intraprendere una delle seguenti azioni.

  • Aumentare la dimensione del pool di connessioni,

  • Aumentare il timeout di acquisizione.

  • Rallenta la frequenza delle richieste.

  Aumentando il numero massimo di connessioni, è possibile aumentare la velocità effettiva del client (a meno che l'interfaccia di rete non sia già completamente utilizzata). Tuttavia, alla fine è possibile raggiungere le limitazioni del sistema operativo relative al numero di descrittori di file utilizzati dal processo. Se utilizzi già completamente l'interfaccia di rete o non riesci ad aumentare ulteriormente il numero di connessioni, prova ad aumentare il timeout di acquisizione. Con l'aumento, avrai più tempo a disposizione per le richieste di acquisizione di una connessione prima del timeout. Se le connessioni non si liberano, le richieste successive continueranno a scadere.

  Se non riesci a risolvere il problema utilizzando i primi due meccanismi, rallenta la frequenza delle richieste provando le seguenti opzioni.

  • Semplifica le tue richieste in modo che i grandi picchi di traffico non sovraccarichino il client.

  • Sii più efficiente con le chiamate a. Servizi AWS

  • Aumenta il numero di host che inviano richieste.

• I thread di I/O sono troppo occupati. Questo vale solo se si utilizza un client SDK asincrono con. NettyNioAsyncHttpClient Se la AvailableConcurrency metrica non è bassa, ovvero indica che le connessioni sono disponibili nel pool, ma ConcurrencyAcquireDuration è elevata, è possibile che i thread di I/O non siano in grado di gestire le richieste. Assicurati di non passare Runnable:run per un futuro esecutore di completamento e di non eseguire attività dispendiose in termini di tempo nella catena di completamento delle risposte future, poiché ciò può bloccare un thread di I/O. In caso contrario, valuta la possibilità di aumentare il numero di thread di I/O utilizzando il metodo. eventLoopGroupBuilder Per riferimento, il numero predefinito di thread di I/O per un'NettyNioAsyncHttpClientistanza è il doppio del numero di core CPU dell'host.

• Latenza di handshake TLS elevata. Se la AvailableConcurrency metrica è vicina a 0 ed LeasedConcurrency è inferiore aMaxConcurrency, è possibile che la latenza dell'handshake TLS sia elevata. Il grafico seguente mostra come potrebbero apparire le metriche SDK per un'elevata latenza di handshake TLS.

  

  Per i client HTTP offerti da Java SDK che non sono basati su CRT, provate ad abilitare i log TLS per risolvere i problemi TLS. Per il client HTTP basato su CRT, prova ad AWS abilitare i log CRT.AWS Se notate che l' AWS endpoint sembra impiegare molto tempo per eseguire un handshake TLS, contattate il servizio interessato.

Come posso riparare unNoClassDefFoundError, or? NoSuchMethodErrorNoSuchFieldError

A NoClassDefFoundError indica che non è stato possibile caricare una classe in fase di esecuzione. Le due cause più comuni di questo errore sono:

• la classe non esiste nel classpath perché nel classpath manca il JAR o nel classpath è presente una versione errata del JAR.

• la classe non è stata caricata perché il suo inizializzatore statico ha generato un'eccezione.

Allo stesso modo, NoSuchMethodError s e NoSuchFieldError s in genere derivano da una versione JAR non corrispondente. Si consiglia di eseguire le seguenti operazioni.

1. Controlla le tue dipendenze per assicurarti di utilizzare la stessa versione di tutti i jar SDK. Il motivo più comune per cui non è possibile trovare una classe, un metodo o un campo è quando esegui l'aggiornamento a una nuova versione del client ma continui a utilizzare una vecchia versione di dipendenza SDK «condivisa». La nuova versione del client potrebbe tentare di utilizzare classi che esistono solo nelle dipendenze SDK «condivise» più recenti. Prova a eseguire mvn dependency:tree o gradle dependencies (per Gradle) a verificare che tutte le versioni della libreria SDK corrispondano. Per evitare completamente questo problema in futuro, consigliamo di utilizzare BOM (Bill of Materials) per gestire le versioni dei moduli SDK.

   L'esempio seguente mostra un esempio di versioni SDK miste.

   [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

   La versione di dynamodb è 2.20.00 e la versione di aws-core è 2.13.19. Anche la versione degli aws-core artefatti dovrebbe essere la 2.20.00.

2. Controlla le istruzioni nelle prime fasi dei log per vedere se una classe non riesce a caricarsi a causa di un errore di inizializzazione statico. La prima volta che la classe non riesce a caricarsi, potrebbe generare un'eccezione diversa e più utile che specifica il motivo per cui la classe non può essere caricata. Questa eccezione potenzialmente utile si verifica solo una volta, quindi le istruzioni di registro successive segnaleranno solo che la classe non è stata trovata.

3. Controllate il processo di distribuzione per assicurarvi che distribuisca effettivamente i file JAR richiesti insieme all'applicazione. È possibile che tu stia compilando con la versione corretta, ma il processo che crea il classpath per l'applicazione esclude una dipendenza richiesta.

Come posso correggere un errore "SignatureDoesNotMatch" o l'errore «La firma della richiesta che abbiamo calcolato non corrisponde alla firma che hai fornito»?

Un SignatureDoesNotMatch errore indica che la firma generata da AWS SDK for Java e la firma generata da Servizio AWS non corrispondono. I seguenti elementi descrivono le cause potenziali.

• Un delegato o un intermediario modifica la richiesta. Ad esempio, un proxy o un load balancer potrebbe modificare un'intestazione, un percorso o una stringa di query firmata dall'SDK.

• Il servizio e l'SDK differiscono nel modo in cui codificano la richiesta quando ciascuno genera la stringa da firmare.

Per eseguire il debug di questo problema, ti consigliamo di abilitare la registrazione di debug per l'SDK. Prova a riprodurre l'errore e trova la richiesta canonica generata dall'SDK. Nel registro, la richiesta canonica è etichettata con AWS4 Canonical Request: ... e la stringa da firmare è etichettata. AWS4 String to sign: ...

Se non puoi abilitare il debug, ad esempio perché è riproducibile solo in produzione, aggiungi una logica all'applicazione che registra le informazioni sulla richiesta quando si verifica l'errore. È quindi possibile utilizzare tali informazioni per provare a replicare l'errore al di fuori della produzione in un test di integrazione con la registrazione di debug abilitata.

Dopo aver raccolto la richiesta canonica e la stringa da firmare, confrontale con la specifica AWS Signature Version 4 per determinare se ci sono problemi nel modo in cui l'SDK ha generato la stringa da firmare. Se qualcosa sembra sbagliato, puoi creare una segnalazione di GitHub bug a. AWS SDK for Java

Se non appare nulla di sbagliato, puoi confrontare la stringa dell'SDK da firmare con la stringa per firmare che alcuni Servizi AWS restituiscono come parte della risposta all'errore (Amazon S3, ad esempio). Se non è disponibile, contatta il servizio interessato per vedere quale richiesta canonica e stringa da firmare hanno generato per il confronto. Questi confronti possono aiutare a identificare gli intermediari che potrebbero aver modificato la richiesta o le differenze di codifica tra il servizio e il client.

Per ulteriori informazioni di base sulla firma delle richieste, consulta Firmare le richieste AWS API nella Guida per l' AWS Identity and Access Management utente.

Esempio di una richiesta canonica

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

Esempio di una stringa da firmare

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

Come posso correggere l'errore "java.lang.IllegalStateException: Connection pool shut down»?

Questo errore indica che il pool di connessioni HTTP Apache sottostante è stato chiuso. I seguenti elementi descrivono le cause potenziali.

• Il client SDK è stato chiuso prematuramente.L'SDK chiude il pool di connessioni solo quando il client associato viene chiuso. Assicurati di non chiudere le risorse mentre sono in uso.

• È java.lang.Error stato lanciato A. Errori come quello che OutOfMemoryError causa la chiusura di un pool di connessioni HTTP di Apache. Esamina i log per individuare eventuali tracce dello stack di errori. Esamina anche il codice per individuare i punti in cui rileva Throwable s o Error s ma ingoia l'output che impedisce la comparsa dell'errore. Se il codice non riporta errori, riscrivilo in modo che le informazioni vengano registrate. Le informazioni registrate aiutano a determinare la causa principale dell'errore.

• Hai tentato di utilizzare il provider di credenziali restituito DefaultCredentialsProvider#create() dopo la sua chiusura. DefaultCredentialsProvider#createrestituisce un'istanza singleton, quindi se è chiusa e il codice chiama il resolveCredentials metodo, l'eccezione viene generata dopo la scadenza delle credenziali (o token) memorizzate nella cache.

  Controlla il codice per individuare i punti in cui DefaultCredentialsProvider è chiuso, come illustrato negli esempi seguenti.

  • L'istanza singleton viene chiusa chiamando DefaultCredentialsProvider#close().

    DefaultCredentialsProvider defaultCredentialsProvider = DefaultCredentialsProvider.create(); // Singleton instance returned.
    AwsCredentials credentials = defaultCredentialsProvider.resolveCredentials();
    
    // Make calls to Servizi AWS.
    
    defaultCredentialsProvider.close();  // Explicit close.
    
    // Make calls to Servizi AWS.
    
    // 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();

  • Invoca DefaultCredentialsProvider#create() in un blocco. try-with-resources

    try (DefaultCredentialsProvider defaultCredentialsProvider = DefaultCredentialsProvider.create()) {
        AwsCredentials credentials = defaultCredentialsProvider.resolveCredentials();
        
        // Make calls to Servizi AWS.
    
    } // After the try-with-resources block exits, the singleton DefaultCredentialsProvider is closed.
    
    // Make calls to Servizi AWS.
    
    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();

  Crea una nuova istanza non singleton chiamando DefaultCredentialsProvider.builder().build() se il tuo codice ha chiuso l'istanza singleton e devi risolvere le credenziali utilizzando un. DefaultCredentialsProvider