FAQ penyelesaian masalah - AWS SDK for Java 2.x

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

FAQ penyelesaian masalah

Saat Anda menggunakan AWS SDK for Java 2.x dalam aplikasi Anda, Anda mungkin menemukan kesalahan runtime yang tercantum dalam topik ini. Gunakan saran di sini untuk membantu Anda mengungkap akar penyebab dan menyelesaikan kesalahan.

Bagaimana cara memperbaiki kesalahan "java.net.SocketException: Pengaturan ulang koneksi” atau “server gagal menyelesaikan respons”?

Kesalahan penyetelan ulang koneksi menunjukkan bahwa host Anda AWS layanan, pihak, atau pihak perantara (misalnya, gateway NAT, proxy, penyeimbang beban) menutup koneksi sebelum permintaan selesai. Karena ada banyak penyebab, menemukan solusi mengharuskan Anda tahu mengapa koneksi ditutup. Item berikut biasanya menyebabkan koneksi ditutup.

  • Koneksi tidak aktif.Ini umum untuk operasi streaming, di mana data tidak ditulis ke atau dari kawat untuk jangka waktu tertentu, sehingga pihak perantara mendeteksi koneksi sebagai mati dan menutupnya. Untuk mencegah hal ini, pastikan aplikasi Anda secara aktif mengunduh atau mengunggah data.

  • Anda telah menutup klien HTTP atau SDK. Pastikan untuk tidak menutup sumber daya saat sedang digunakan.

  • Proxy yang salah dikonfigurasi. Cobalah untuk melewati proxy apa pun yang telah Anda konfigurasikan untuk melihat apakah itu memperbaiki masalah. Jika ini memperbaiki masalah, proxy menutup koneksi Anda karena alasan tertentu. Teliti proxy spesifik Anda untuk menentukan mengapa itu menutup koneksi.

Jika Anda tidak dapat mengidentifikasi masalah, coba jalankan dump TCP untuk koneksi yang terpengaruh di tepi klien jaringan Anda (misalnya, setelah proxy apa pun yang Anda kontrol).

Jika Anda melihat bahwa AWS titik akhir mengirim TCP RST (reset), hubungi layanan yang terpengaruh untuk melihat apakah mereka dapat menentukan mengapa reset terjadi. Bersiaplah untuk memberikan ID permintaan dan stempel waktu kapan masalah terjadi. Tim AWS dukungan mungkin juga mendapat manfaat dari log kawat yang menunjukkan dengan tepat byte apa yang dikirim dan diterima aplikasi Anda dan kapan.

Bagaimana cara memperbaiki “batas waktu koneksi”?

Kesalahan batas waktu koneksi menunjukkan bahwa host Anda, pihak AWS layanan, atau pihak perantara (misalnya, gateway NAT, proxy, penyeimbang beban) gagal membuat koneksi baru dengan server dalam batas waktu koneksi yang dikonfigurasi. Item berikut menjelaskan penyebab umum masalah ini.

  • Batas waktu koneksi yang dikonfigurasi terlalu rendah. Secara default, batas waktu koneksi adalah 2 detik di file. AWS SDK for Java 2.x Jika Anda mengatur batas waktu koneksi terlalu rendah, Anda mungkin mendapatkan kesalahan ini. Batas waktu koneksi yang disarankan adalah 1 detik jika Anda hanya melakukan panggilan di wilayah dan 3 detik jika Anda membuat permintaan lintas wilayah.

  • Proxy yang salah dikonfigurasi. Cobalah untuk melewati proxy apa pun yang Anda konfigurasikan untuk melihat apakah itu memperbaiki masalah. Jika ini memperbaiki masalah, proxy adalah alasan batas waktu koneksi. Teliti proxy spesifik Anda untuk menentukan mengapa hal itu terjadi

Jika Anda tidak dapat mengidentifikasi masalah, coba jalankan dump TCP untuk koneksi yang terpengaruh di tepi klien jaringan Anda (misalnya, setelah proxy apa pun yang Anda kontrol) untuk menyelidiki masalah jaringan apa pun.

Bagaimana cara memperbaiki "java.net.SocketTimeoutException: Baca waktunya habis”?

Kesalahan waktu baca menunjukkan bahwa JVM berusaha membaca data dari sistem operasi yang mendasarinya, tetapi data tidak dikembalikan dalam waktu yang dikonfigurasi melalui SDK. Kesalahan ini dapat terjadi jika sistem operasi, pihak AWS layanan, atau pihak perantara (misalnya, gateway NAT, proxy, penyeimbang beban) gagal mengirim data dalam waktu yang diharapkan oleh JVM. Karena ada banyak penyebab, menemukan solusi mengharuskan Anda tahu mengapa data tidak dikembalikan.

Coba jalankan dump TCP untuk koneksi yang terpengaruh di tepi klien jaringan Anda (misalnya, setelah proxy apa pun yang Anda kontrol).

Jika Anda melihat bahwa AWS titik akhir mengirim TCP RST (reset), hubungi layanan yang terpengaruh. Bersiaplah untuk memberikan ID permintaan dan stempel waktu kapan masalah terjadi. Tim AWS dukungan mungkin juga mendapat manfaat dari log kawat yang menunjukkan dengan tepat byte apa yang dikirim dan diterima aplikasi Anda dan kapan.

Bagaimana cara memperbaiki kesalahan “Tidak dapat menjalankan permintaan HTTP: Timeout waiting for connection from pool”?

Kesalahan ini menunjukkan bahwa permintaan tidak bisa mendapatkan koneksi dari pool dalam waktu maksimum yang ditentukan. Untuk mengatasi masalah ini, sebaiknya aktifkan metrik sisi klien SDK untuk memublikasikan metrik ke Amazon. CloudWatch Metrik HTTP dapat membantu mempersempit akar penyebabnya. Item berikut menjelaskan penyebab umum kesalahan ini.

  • Kebocoran koneksi. Anda dapat menyelidiki ini dengan memeriksaLeasedConcurrency,AvailableConcurrency, dan MaxConcurrency metrik. Jika LeasedConcurrency meningkat hingga mencapai MaxConcurrency tetapi tidak pernah berkurang, mungkin ada kebocoran koneksi. Penyebab umum kebocoran adalah karena operasi streaming — seperti metode getObject S3 — tidak ditutup. Kami menyarankan agar aplikasi Anda membaca semua data dari aliran input sesegera mungkin dan menutup aliran input setelahnya. Bagan berikut menunjukkan seperti apa metrik SDK untuk kebocoran koneksi.

    Tangkapan layar CloudWatch metrik yang menunjukkan kemungkinan kebocoran koneksi.
  • Kelaparan kolam koneksi.Hal ini dapat terjadi jika tingkat permintaan Anda terlalu tinggi dan ukuran kumpulan koneksi yang telah dikonfigurasi tidak dapat memenuhi permintaan permintaan. Ukuran kumpulan koneksi default adalah 50, dan ketika koneksi di kolam mencapai maksimum, klien HTTP mengantri permintaan masuk hingga koneksi tersedia. Bagan berikut menunjukkan seperti apa metrik SDK untuk kelaparan kumpulan koneksi.

    Tangkapan layar CloudWatch metrik yang menunjukkan bagaimana kelaparan kumpulan koneksi mungkin terlihat.

    Untuk mengurangi masalah ini, pertimbangkan untuk mengambil salah satu tindakan berikut.

    • Tingkatkan ukuran kolam koneksi,

    • Tingkatkan batas waktu akuisisi.

    • Memperlambat tingkat permintaan.

    Dengan meningkatkan jumlah maksimum koneksi, throughput klien dapat meningkat (kecuali antarmuka jaringan sudah sepenuhnya digunakan). Namun, Anda akhirnya dapat menekan batasan sistem operasi pada jumlah deskriptor file yang digunakan oleh proses. Jika Anda sudah sepenuhnya menggunakan antarmuka jaringan Anda atau tidak dapat meningkatkan jumlah koneksi Anda lebih lanjut, coba tingkatkan batas waktu perolehan. Dengan peningkatan ini, Anda mendapatkan waktu ekstra untuk permintaan untuk mendapatkan koneksi sebelum waktu habis. Jika koneksi tidak bebas, permintaan berikutnya akan tetap batas waktu.

    Jika Anda tidak dapat memperbaiki masalah dengan menggunakan dua mekanisme pertama, perlambat tingkat permintaan dengan mencoba opsi berikut.

    • Menghaluskan permintaan Anda sehingga semburan lalu lintas yang besar tidak membebani klien.

    • Jadilah lebih efisien dengan panggilan ke AWS layanan.

    • Tingkatkan jumlah host yang mengirim permintaan.

  • I/O Thread terlalu sibuk. Ini hanya berlaku jika Anda menggunakan klien SDK asinkron dengan. NettyNioAsyncHttpClient Jika AvailableConcurrency metriknya tidak rendah—menunjukkan bahwa koneksi tersedia di kolam—tetapi ConcurrencyAcquireDuration tinggi, mungkin karena utas I/O tidak dapat menangani permintaan. Pastikan Anda tidak lulus Runnable:run sebagai pelaksana penyelesaian masa depan dan melakukan tugas yang memakan waktu dalam rantai penyelesaian masa depan respons karena ini dapat memblokir utas I/O. Jika bukan itu masalahnya, pertimbangkan untuk menambah jumlah utas I/O dengan menggunakan eventLoopGroupBuilder metode ini. Sebagai referensi, jumlah default thread I/O untuk sebuah NettyNioAsyncHttpClient instance adalah dua kali jumlah core CPU host.

  • Latensi jabat tangan TLS tinggi. Jika AvailableConcurrency metrik Anda mendekati 0 dan LeasedConcurrency lebih rendah dariMaxConcurrency, mungkin karena latensi jabat tangan TLS tinggi. Bagan berikut menunjukkan seperti apa metrik SDK untuk latensi jabat tangan TLS yang tinggi.

    Tangkapan layar CloudWatch metrik yang mungkin menunjukkan latensi jabat tangan TLS yang tinggi.

    Untuk klien HTTP yang ditawarkan oleh Java SDK yang tidak didasarkan pada CRT, coba aktifkan log TLS untuk memecahkan masalah TLS. Untuk klien HTTP AWS berbasis CRT, coba aktifkan AWS log CRT. Jika Anda melihat bahwa AWS titik akhir tampaknya membutuhkan waktu lama untuk melakukan jabat tangan TLS, Anda harus menghubungi layanan yang terpengaruh.

Bagaimana cara memperbaikiNoClassDefFoundError, NoSuchMethodError atauNoSuchFieldError?

A NoClassDefFoundError menunjukkan bahwa kelas tidak dapat dimuat saat runtime. Dua penyebab paling umum untuk kesalahan ini adalah:

  • kelas tidak ada di classpath karena JAR hilang atau versi JAR yang salah ada di classpath.

  • kelas gagal memuat karena penginisialisasi statisnya memberikan pengecualian.

Demikian pula, NoSuchMethodError s dan NoSuchFieldError s biasanya dihasilkan dari versi JAR yang tidak cocok. Kami menyarankan Anda melakukan langkah-langkah berikut.

  1. Periksa dependensi Anda untuk memastikan bahwa Anda menggunakan versi yang sama dari semua stoples SDK. Alasan paling umum bahwa kelas, metode, atau bidang tidak dapat ditemukan adalah ketika Anda meningkatkan ke versi klien baru tetapi Anda terus menggunakan versi ketergantungan SDK 'bersama' lama. Versi klien baru mungkin mencoba menggunakan kelas yang hanya ada di dependensi SDK 'bersama' yang lebih baru. Coba jalankan mvn dependency:tree atau gradle dependencies (untuk Gradle) untuk memverifikasi bahwa semua versi pustaka SDK cocok. Untuk menghindari masalah ini sepenuhnya di masa mendatang, sebaiknya gunakan BOM (Bill of Materials) untuk mengelola versi modul SDK.

    Contoh berikut menunjukkan contoh versi SDK campuran.

    [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

    Versi dynamodb adalah 2.20.00 dan versi 2.13.19aws-core. Versi aws-core artefak juga harus 2.20.00.

  2. Periksa pernyataan di awal log Anda untuk melihat apakah kelas gagal dimuat karena kegagalan inisialisasi statis. Pertama kali kelas gagal memuat, mungkin ada pengecualian yang berbeda dan lebih berguna yang menentukan mengapa kelas tidak dapat dimuat. Pengecualian yang berpotensi berguna ini hanya terjadi sekali, jadi pernyataan log selanjutnya hanya akan melaporkan bahwa kelas tidak ditemukan.

  3. Periksa proses penyebaran Anda untuk memastikan bahwa itu benar-benar menyebarkan file JAR yang diperlukan bersama dengan aplikasi Anda. Ada kemungkinan bahwa Anda sedang membangun dengan versi yang benar, tetapi proses yang membuat classpath untuk aplikasi Anda tidak termasuk dependensi yang diperlukan.

Bagaimana cara memperbaiki kesalahan "SignatureDoesNotMatch" atau “Tanda tangan permintaan yang kami hitung tidak cocok dengan tanda tangan yang Anda berikan”?

SignatureDoesNotMatchKesalahan menunjukkan bahwa tanda tangan yang dihasilkan oleh AWS SDK for Java dan tanda tangan yang dihasilkan oleh AWS layanan tidak cocok. Item berikut menjelaskan penyebab potensial.

  • Pihak proxy atau perantara memodifikasi permintaan. Misalnya, proxy atau penyeimbang beban dapat mengubah header, path, atau string kueri yang ditandatangani oleh SDK.

  • Layanan dan SDK berbeda dalam cara mereka menyandikan permintaan ketika masing-masing menghasilkan string untuk ditandatangani.

Untuk men-debug masalah ini, sebaiknya aktifkan logging debug untuk SDK. Cobalah untuk mereproduksi kesalahan dan temukan permintaan kanonik yang dihasilkan SDK. Di log, permintaan kanonik diberi label AWS4 Canonical Request: ... dan string yang akan ditandatangani diberi label. AWS4 String to sign: ...

Jika Anda tidak dapat mengaktifkan debugging—misalnya, karena hanya dapat direproduksi dalam produksi—tambahkan logika ke aplikasi Anda yang mencatat informasi tentang permintaan saat terjadi kesalahan. Anda kemudian dapat menggunakan informasi tersebut untuk mencoba mereplikasi kesalahan di luar produksi dalam pengujian integrasi dengan logging debug diaktifkan.

Setelah Anda mengumpulkan permintaan kanonik dan string untuk ditandatangani, bandingkan dengan spesifikasi AWS Signature Version 4 untuk menentukan apakah ada masalah dalam cara SDK menghasilkan string untuk ditandatangani. Jika ada yang tidak beres, Anda dapat membuat laporan GitHub bug ke file AWS SDK for Java.

Jika tidak ada yang salah, Anda dapat membandingkan string SDK untuk ditandatangani dengan string untuk menandatangani bahwa beberapa AWS layanan kembali sebagai bagian dari respons kegagalan (Amazon S3, misalnya). Jika ini tidak tersedia, Anda harus menghubungi layanan yang terpengaruh untuk melihat permintaan dan string kanonik apa yang akan ditandatangani yang dihasilkan untuk perbandingan. Perbandingan ini dapat membantu mengidentifikasi pihak perantara yang mungkin telah memodifikasi permintaan atau menyandikan perbedaan antara layanan dan klien.

Untuk informasi latar belakang selengkapnya tentang permintaan penandatanganan, lihat Menandatangani permintaan AWS API di Panduan AWS Identity and Access Management Pengguna.

contoh dari permintaan kanonik
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
contoh dari string untuk ditandatangani
AWS4-HMAC-SHA256 20240308T034435Z 20240308/us-east-1/s3/aws4_request 5f20a7604b1ef65dd89c333fd66736fdef9578d11a4f5d22d289597c387dc713

Bagaimana cara memperbaiki kesalahan "java.lang.IllegalStateException: Connection pool shut down”?

Kesalahan ini menunjukkan kumpulan koneksi HTTP Apache yang mendasarinya ditutup. Item berikut menjelaskan penyebab potensial.

  • Klien SDK ditutup sebelum waktunya.SDK hanya menutup kumpulan koneksi saat klien terkait ditutup. Pastikan untuk tidak menutup sumber daya saat sedang digunakan.

  • A java.lang.Error dilemparkan. Kesalahan seperti OutOfMemoryError menyebabkan kolam koneksi HTTP Apache dimatikan. Periksa log Anda untuk jejak tumpukan kesalahan. Juga tinjau kode Anda untuk tempat-tempat di mana ia menangkap Throwable s atau Error s tetapi menelan output yang mencegah kesalahan muncul ke permukaan. Jika kode Anda tidak melaporkan kesalahan, tulis ulang kode sehingga informasi dicatat. Informasi yang dicatat membantu menentukan akar penyebab kesalahan.

  • Anda mencoba menggunakan penyedia kredensyal yang dikembalikan DefaultCredentialsProvider#create() setelah ditutup. DefaultCredentialsProvider#createmengembalikan instance tunggal, jadi jika ditutup dan kode Anda memanggil resolveCredentials metode, pengecualian dilemparkan setelah kredensi cache (atau token) kedaluwarsa.

    Periksa kode Anda untuk tempat-tempat di mana DefaultCredentialsProvider ditutup, seperti yang ditunjukkan pada contoh berikut.

    • Instance singleton ditutup dengan memanggil DefaultCredentialsProvider#close().

      DefaultCredentialsProvider defaultCredentialsProvider = DefaultCredentialsProvider.create(); // Singleton instance returned. AwsCredentials credentials = defaultCredentialsProvider.resolveCredentials(); // Make calls to AWS layanan. defaultCredentialsProvider.close(); // Explicit close. // Make calls to AWS layanan. // 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();
    • Memanggil DefaultCredentialsProvider#create() dalam satu try-with-resources blok.

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

    Buat instance baru, non-singleton dengan memanggil DefaultCredentialsProvider.builder().build() jika kode Anda telah menutup instance tunggal dan Anda perlu menyelesaikan kredensialnya dengan menggunakan file. DefaultCredentialsProvider