3

私の Android アプリは、AWS Java SDK を使用してユーザーの写真を S3 にアップロードします。

ユーザーの電話の時計がずれていると、すべての転送が失敗します。これは、S3 の十分に文書化された側面です。

http://aws.amazon.com/articles/1109?_encoding=UTF8&jiveRedirect=1#04

アップストリームの S3 サービスがこのエラーを非常に明確に報告しているようです。

HTTP ステータス コード: 403 禁止

エラー コード: RequestTimeToo-Skewed

説明: 要求時間とサーバー時間の差が大きすぎます。

ただし、Java SDK を使用すると、有益な 403 コードが失われたように見えます...そして、通過する不透明な「TransferState.Failed」しかありません (これは、インターネット接続が失われた場合と同じエラーです。など)。

ドキュメントからわかる限り:

http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/index.html http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/TransferProgress .html http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/Transfer.TransferState.html http://docs.aws.amazon.com/AWSJavaSDK/latest /javadoc/com/amazonaws/services/s3/transfer/Upload.html

転送の失敗に関する追加の「RequestTimeToo-Skewed」メタデータを取得する方法はありません。

私はそれを見逃していますか?Amazon の Java SDK を使用して S3 転送が失敗した場合に、追加のエラー情報を取得する方法はありますか?

更新 #1: コメント投稿者は、2 つの点を明確にする必要があることを親切に強調しました。

  • 私は実際に AWS SDK for Android を使用しています (これは Java SDK に非常に似ているように見えますが、それでも異なります)。
  • TransferManager クラスを使用してアップロードを実行しています。どうやら、これは低レベルの AmazonS3Client をラップする高レベルのクラスであり、この低レベルのクラスは必要なエラー レポートを公開する必要がありますが、TransferManager と AmazonS3Client の間に含まれる正確なトレードオフについてはまだ調査中です。私が知る限り、(同期) AmazonS3Client.putObjectRequest を介して進行状況情報を取得する方法はありません。これは私にとってブロッカーになります...

更新 #2: ここに立ち寄って私を助けてくれた (AWS SDK チームの) Jason に心から感謝します。実際、特定のメソッドを使用すると、重要な情報は AmazonS3Exception のプロパティとして利用できます。ドキュメントはもともと私を混乱させ、ステータスをポーリングするには手動の Thread.sleep() ループが必要だと思っていました (したがって、waitForCompletion または waitForException を活用できませんでした)。しかし、PutObjectRequest で ProgressListener を使用すると、完全な進行状況のコールバックとAmazonS3Exception のエラー忠実度。

4

2 に答える 2

5

次の 2 つの方法が役に立ちます。

転送進行イベントに基づいて転送が失敗したことを検出した場合は、単純に Transfer.waitForException() を呼び出して、発生した例外を返すことができます。この場合、その例外は AmazonServiceException になり、実際の問題がクロック スキューの問題であったことを確認するために必要なすべての情報が含まれます。

または、このTransfer.waitForCompletion()メソッドは、ExecutionException から元の例外をラップ解除し、元の例外を直接スローします。これは、すべてが 1 つのスレッドで発生しているかのように行われます。これは、catch ブロックを使用してさまざまな種類のエラーをクリーンかつエレガントにキャッチする場合に便利な方法です。

「catch Exception」ブロックが「残酷に広い」ことに同意しません。そのコードのポイントは、発生したエラーをキャッチし、転送を失敗としてマークし、エラーを再スローして、アプリケーション コードがそれを認識できるようにすることです。範囲が狭い場合はまさに例外が忍び寄り、転送の進行状況が正しく更新されず、現実と同期しなくなる可能性があります.

これらの 2 つの方法とショットを指定して、それが役立つかどうかをお知らせください。

于 2013-02-23T01:09:40.990 に答える
1

さて、私は Amazon の SDK をデバッグしましたが、この情報が内部で飲み込まれていると言って申し訳ありません。おそらく、私はパッチを提出しようとします。

詳細: AmazonS3Exception が内部的にスローされ、実際にはこの正確なエラー シナリオを正確に報告しますが、非常に広範な try catch ( Exception e ) がそれを消費し、特異性を洗い流します。

有罪のトライキャッチは次のとおりです。

https://github.com/aws/aws-sdk-java/blob/master/src/main/java/com/amazonaws/services/s3/transfer/internal/UploadMonitor.java#L145

これは、正しい情報で AmazonS3Exception が正しくスローされることを示すスクリーンショットです...

デバッグ スクリーンショット

于 2013-02-23T00:13:15.413 に答える