As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Solução de problemas FAQs
Ao usar o AWS SDK para Kotlin em seus aplicativos, você pode encontrar alguns dos problemas listados neste tópico. Use as sugestões a seguir para ajudar a descobrir a causa raiz e resolver o erro.
## Como faço para corrigir problemas de “conexão fechada”?
Você pode encontrar problemas de “conexão fechada” como exceções, como um dos seguintes tipos:
+ `IOException: unexpected end of stream on `
+ `EOFException: \n not found: limit=0`
+ `HttpException: AWS_ERROR_HTTP_CONNECTION_CLOSED: The connection has closed or is closing.; crtErrorCode=2058; HttpErrorCode(CONNECTION_CLOSED)`
Essas exceções indicam que uma conexão TCP do SDK com um serviço foi fechada ou redefinida inesperadamente. A conexão pode ter sido fechada pelo seu host, pelo AWS serviço ou por uma parte intermediária, como um gateway NAT, proxy ou balanceador de carga.
Esses tipos de exceções são repetidos automaticamente, mas ainda podem aparecer nos registros do SDK, dependendo da sua configuração de registro. Se a exceção for inserida em seu código, isso indica que a estratégia de repetição ativa esgotou seus limites configurados, como o máximo de tentativas ou o repositório de tokens de repetição. Consulte a [Tentativas novamente no AWS SDK para Kotlin](retries.md) seção deste guia para obter mais informações sobre estratégias de repetição. Consulte também [Por que as exceções são lançadas antes de atingir o máximo de tentativas?](#ts-faq-exceptions-before-max).
### Monitoramento de conexão inativa com o OkHttpEngine
Se você estiver usando o `OkHttpEngine` e frequentemente encontrar `IOException: unexpected end of stream on ` exceções, [considere ativar o monitoramento de conexões ociosas](http-client-config.md#http-idle-connection-monitoring). Esse recurso detecta quando servidores remotos têm conexões fechadas que ainda estão no pool de conexões, o que pode reduzir a ocorrência dessas exceções.
## Por que as exceções são lançadas antes de atingir o máximo de tentativas?
Às vezes, você pode ver exceções que esperava que fossem repetidas, mas que, em vez disso, foram descartadas. Nessas situações, as etapas a seguir podem ajudar a resolver o problema.
+ **Verifique se a exceção pode ser repetida.** Algumas exceções não podem ser repetidas, como aquelas que indicam uma solicitação de serviço malformada, falta de permissões e recursos inexistentes, como exemplos. O SDK não repete automaticamente esses tipos de exceções. Para obter informações sobre como verificar exceções que podem ser repetidas, consulte. [Verifique se uma exceção pode ser repetida](retries.md#retries-check-exception-retryable)
+ **Verifique se a exceção está sendo inserida em seu código.** Algumas exceções aparecem nas mensagens de log como informações, mas na verdade não são incluídas em seu código. Por exemplo, exceções que podem ser repetidas, como erros de limitação, podem ser registradas, pois o SDK funciona automaticamente em vários ciclos. backoff-and-retry A invocação de uma operação do SDK gera uma exceção somente se não for tratada pelas configurações de repetição definidas.
+ **Verifique suas configurações de repetição definidas.** Consulte a [Tentativas novamente no AWS SDK para Kotlin](retries.md) seção deste guia para obter mais informações sobre estratégias e políticas de repetição. Certifique-se de que seu código esteja usando as configurações esperadas ou os padrões automáticos.
+ **Considere ajustar suas configurações de nova tentativa.** Depois de verificar os itens anteriores, mas o problema não ter sido resolvido, você pode considerar ajustar as configurações de nova tentativa.
+ **Aumente o número máximo de tentativas.** Por padrão, o número máximo de tentativas de uma operação é 3. Se você achar que isso não é suficiente e as exceções ainda estão ocorrendo na configuração padrão, considere aumentar a `retryStrategy.maxAttempts` propriedade na configuração do seu cliente. Consulte [Configurar o máximo de tentativas](retries.md#retires-max-attempts) para obter mais informações.
+ **Aumente as configurações de atraso.** Algumas exceções podem ser repetidas muito rapidamente antes que a condição subjacente tenha a chance de ser resolvida. Se você suspeitar que esse seja o caso, considere aumentar as `retryStrategy.delayProvider.maxBackoff` propriedades `retryStrategy.delayProvider.initialDelay` ou na configuração do seu cliente. Consulte [Configure atrasos e recuos](retries.md#retries-delays-backoff) para obter mais informações.
+ **Desative o modo disjuntor.** Por padrão, o SDK mantém um bucket de tokens para cada cliente de serviço. Quando o SDK tenta uma solicitação e ela falha com uma exceção que pode ser repetida, a contagem de tokens é diminuída; quando a solicitação é bem-sucedida, a contagem de tokens é incrementada.
Por padrão, se esse token bucket atingir 0 tokens restantes, o circuito será interrompido. Depois que o circuito é interrompido, o SDK desativa as novas tentativas e todas as solicitações atuais e subsequentes que falharem na primeira tentativa geram imediatamente uma exceção. O SDK reativa as novas tentativas após as tentativas iniciais bem-sucedidas retornarem capacidade suficiente ao token bucket. Esse comportamento é intencional e foi projetado para evitar novas tentativas durante interrupções e recuperação do serviço.
Se você preferir que o SDK continue tentando novamente até o máximo de tentativas configuradas, considere desativar o modo disjuntor definindo a `retryStrategy.tokenBucket.useCircuitBreakerMode` propriedade como false na configuração do seu cliente. Com essa propriedade definida como false, o cliente SDK espera até que o token bucket atinja a capacidade suficiente, em vez de abandonar novas tentativas, o que pode levar a uma exceção quando houver 0 tokens restantes.
## Como faço para corrigir `NoSuchMethodError` ou NoClassDefFoundError?
Esses erros geralmente são causados por dependências ausentes ou conflitantes. Consulte [Como faço para resolver conflitos de dependência?](ts-faq-dep-conflict-resolution.md) para obter mais informações.
### Eu vejo um `NoClassDefFoundError` para `okhttp3/coroutines/ExecuteAsyncKt`
Isso indica um problema de dependência OkHttp específico para. Consulte [Resolvendo conflitos de OkHttp versão em seu aplicativo](ts-faq-dep-conflict-resolution.md#okhttp-dep-conflicts) para obter mais informações.
# Como faço para resolver conflitos de dependência?
Quando você usa o AWS SDK para Kotlin, ele precisa de determinadas dependências AWS e de terceiros para funcionar corretamente. Se essas dependências estiverem ausentes ou forem versões inesperadas em tempo de execução, você poderá ver erros como `NoSuchMethodError` ou`NoClassDefFoundError`. Esses problemas de dependência geralmente se dividem em dois grupos:
+ Conflitos de dependência do SDK/Smithy
+ Conflitos de dependência de terceiros
Ao criar seu aplicativo Kotlin, você provavelmente usará o Gradle para gerenciar dependências. Adicionar uma dependência em um cliente de serviço do SDK ao seu projeto inclui automaticamente todas as dependências relacionadas necessárias. No entanto, se seu aplicativo tiver outras dependências, elas poderão entrar em conflito com as exigidas pelo SDK. Por exemplo, o SDK depende OkHttp de um cliente HTTP popular que seu aplicativo também pode usar. Para ajudar você a identificar esses conflitos, o Gradle oferece uma tarefa útil que lista as dependências do seu projeto:
```
./gradlew dependencies
```
Quando você encontra conflitos de dependência, talvez seja necessário agir. Você pode especificar uma versão específica de uma dependência ou sombrear dependências em um namespace local. A resolução de dependências do Gradle é um tópico complexo discutido nas seções a seguir do Manual do usuário do *Gradle:*
+ [Entendendo a resolução de dependências](https://docs.gradle.org/current/userguide/dependency_resolution.html)
+ [Restrições de dependência e resolução de conflitos](https://docs.gradle.org/current/userguide/dependency_constraints_conflicts.html)
+ [Alinhando versões de dependência](https://docs.gradle.org/current/userguide/dependency_version_alignment.html)
## Gerenciando dependências do SDK e do Smithy em seu projeto
Ao usar o SDK, lembre-se de que seus módulos normalmente dependem de outros módulos do SDK com números de versão correspondentes. Por exemplo, `aws.sdk.kotlin:s3:1.2.3` depende de a`ws.sdk.kotlin:aws-http:1.2.3`, que depende de`aws.sdk.kotlin:aws-core:1.2.3`, e assim por diante.
Os módulos do SDK também usam versões específicas do módulo Smithy. Embora as versões do módulo Smithy não sejam sincronizadas com os números de versão do SDK, elas devem corresponder à versão esperada do SDK. Por exemplo, `aws.sdk.kotlin:s3:1.2.3` pode depender de`aws.smithy.kotlin:serde:1.1.1`, o que depende `aws.smithy.kotlin:runtime-core:1.1.1` e assim por diante.
Para evitar conflitos de dependência, atualize todas as dependências do SDK em conjunto e faça o mesmo com qualquer dependência explícita do Smithy. Considere usar nosso [catálogo de versões do Gradle](setup-create-project-file.md) para manter as versões sincronizadas e eliminar suposições no mapeamento entre as versões do SDK e do Smithy.
Lembre-se de que pequenas atualizações de versão nos SDK/Smithy módulos podem incluir alterações significativas, conforme descrito em nossa política de controle de [versão](https://github.com/awslabs/aws-sdk-kotlin/blob/main/VERSIONING.md#versioning-policy). Ao atualizar entre versões secundárias, analise cuidadosamente os registros de alterações e teste minuciosamente o comportamento do tempo de execução.
## Resolvendo conflitos de OkHttp versão em seu aplicativo
[OkHttp](https://square.github.io/okhttp/)é um mecanismo HTTP popular que o SDK usa por padrão na JVM. Seu aplicativo pode incluir outras dependências ou estruturas que trazem uma versão diferente OkHttp . Isso pode causar um `NoClassDefFoundError` para classes no `okhttp3` namespace, como `okhttp/coroutines/ExecuteAsyncKt` ou. `okhttp3/ConnectionListener` Quando isso acontece, você geralmente deve escolher a versão mais recente para resolver conflitos. Para ajudar você a rastrear as fontes desses conflitos, o Gradle oferece uma tarefa útil. Você pode listar todas as dependências executando:
```
./gradlew dependencies
```
Por exemplo, se o SDK depende de OkHttp `5.0.0-alpha.14` e outra dependência, como Spring Boot, depende OkHttp `4.12.0`, então você deve usar o. `5.0.0-alpha.14 version` Você pode fazer isso com um `constraints` bloco no Gradle:
```
dependencies {
constraints {
implementation("com.squareup.okhttp3:okhttp:4.12.0")
}
}
```
Como alternativa, se você precisar usar o OkHttp 4.x, o SDK fornecerá um. `OkHttp4Engine` Consulte a [documentação](https://github.com/smithy-lang/smithy-kotlin/tree/main/runtime/protocol/http-client-engines/http-client-engine-okhttp4) para obter informações sobre como configurar o Gradle e usá-lo `OkHttp4Engine` em seu código.