5

次の明らかにバグのあるゲッターを含む Java コードを AWS Lambda に誤ってデプロイしました。

public String getLocation() {
   return this.getLocation();
}

Lambda 関数は、15 秒と 320 Mo の制限で構成されています。これは、DynamoDB ストリームによってトリガーされます。問題のあるコードをデプロイした後、22 時 17 分頃に DynamoDB テーブルを変更したため、コードを実行しました。ログを確認したところ、前の関数から予想できるように、非常に長いスタック トレースを伴う従来の StackOverflowError が発生していました。しかし、これが実行を続け、さらにいくつかのスタック オーバーフロー エラー (CloudWatch のログ) を報告し続ける関数を停止しなかったことに驚きました。15秒の制限を過ぎても機能が停止しないことに気付いたとき、私はさらに心配しました. 手動で停止する方法が見つからなかったため、22 時 30 分頃に Lambda コンソールから単純に削除し、最終的に停止させました。

ここに画像の説明を入力

また、私は自分の DynamoDB テーブルに触れていないこと (そして他の誰もそれにアクセスできないこと) も、他の方法で Lambda 関数を実行しようとしたこともないと確信しています。削除するまで数分間実行し続けたのはなぜですか? 私は確かにもっと注意して、最初にローカルで事前テストを実行する必要がありましたが、期間制限は、到達すると何も実行されないことを保証するものではありませんか?

ご協力ありがとうございました。

4

1 に答える 1

9

私はついにこの行動の起源を理解しました。AWS Lambda の公式ドキュメントでは、次のように述べられています。

イベント ソースによっては、AWS Lambda が失敗した Lambda 関数を再試行する場合があります。たとえば、Amazon Kinesis が Lambda 関数のイベント ソースである場合、AWS Lambda は、Lambda 関数が成功するか、ストリーム内のレコードが期限切れになるまで、失敗した関数を再試行します。

DynamoDB ストリームには 24 時間の有効期限の遅延があるため、関数はそれまでに停止するだけです。

于 2016-04-16T17:23:11.763 に答える