2

私はAWSラムダ関数として展開したいnode.js functonを持っています。 Redis Elasticacheを使用すると、redis.createClientで開いた接続を閉じるか、ラムダ関数がタイムアウトすることに気付きました。私は単にクライアントのquit()メソッドを呼び出すだけでこれを行います。ラムダコールバックを発行する前にこれを行うと、ラムダ関数は期待どおりに終了します。私がしなければ、ラムダ関数は設定したタイムアウト間隔でタイムアウトします。テスト設定では、私はキャッシュ上で動作し、30ミリ秒で終了するラムダ関数を持っています。 redis client quit()メソッドを呼び出さなければ、同じラムダ関数は1分のタイムアウト前に終了しません。私は確信していませんが、私はラムダ関数がこのように動作すると仮定しています。なぜなら、redis接続がまだアクティブなので関数が(コールバックの後でも)実行されたかどうかわからないからです。ラムダ関数でDAXクライアントを閉じる

quit()メソッドを呼び出すだけで十分であるので、私はこれについて心配しているわけではありません。私が抱えている問題は、DynamoDB DAXクライアントと同様のことをしようとするときです。私は、ラムダ機能に、私のVPCエンドポイントを介して直接DynamoDBにアクセスさせることができ、すべて正常に動作します。 DAXクライアントを使用すると、テーブルへの変更が実際に行われます(アイテムを挿入してそこにあることがわかります)が、ラムダ関数は常にタイムアウトします。ここで

は、いくつかのサンプルコードです:私はちょうどddbClientを使用する場合は

const AmazonDaxClient = require('amazon-dax-client'); 
const AWS    = require('aws-sdk'); 
const config   = require('./config'); 

AWS.config.update(config.aws); 
var ddbClient = new AWS.DynamoDB.DocumentClient(config.dynamodb); 
var dax = new AmazonDaxClient(config.dax); 
var daxClient = new AWS.DynamoDB.DocumentClient({service: dax }); 

、すべてが動作します。 daxClientを使用すると、すべてが機能します(挿入、削除、更新など)が、ラムダ関数はタイムアウトします。同じようなquit()メソッドがdaxClientのDAXクラスタに伝えられています。完了したら、すべての接続をきれいに閉じることができますか?この問題は、daxClientが通常のddbClientとまったく同じように動作し、ddbClientにquit()メソッドがないようにすることが問題であると考えられます。

+2

'context.callbackWaitsForEmptyEventLoop = false'を設定しようとすると... DAXとredisの両方のタイムアウトに対処し、これらの接続をそれぞれの関数呼び出しで初期化する必要がないので、処理を少し速くすることができます。 (私はDAXクライアントに精通していませんが、Lambdaは誰かがこのオプションを使わずにソケットを開いたままにしておくのを待っています) –

+0

Michael、それは両方の面でそのトリックを行いました。ありがとう!私が受け入れることができるように答えを書きたいのですか? –

答えて

3

ラムダcontextのプロパティcallbackWaitsForEmptyEventLoophereと記載されています)は、あなたのケースに関連している可能性があります。デフォルトではtrueに設定されています。つまり、ノードイベントループ内に何かが残っている限り、ハンドラがコールバック経由で値を返しても、Lambdaはその実行を完了しません。

これを「false」に設定すると、Lambdaハンドラはイベントループ内のものでも完了できますが、Lambdaが実行されていない間はこれらの論理スレッドが実行をフリーズします。この動作は、どれほど堅牢であるかに応じて、すべてのライブラリに適しているとは限りません。

興味深い面白いことに、古いラムダリターンスタイルcontext.succeedcallbackではなく)は、プロパティの設定に関係なく、空のイベントループを待つことはありません。 (This gistにはいくつかの詳細があります)

+0

このソリューションは機能しますが、Lambdaがイベントループで待っていることについてはわかりません。私は、キャッシュ書き込みからのコールバックでラムダコールバックを発行するだけです。だから私が知る限り、イベントループで待っているものはもう一つもないはずです。私は終わったキャッシュへのアクティブな接続しか持っていません。 redisキャッシュでquit()を発行すると問題は解決しましたが、DAXには何も似ていません。このメソッドをDAXでテストした結果、callbackWaitsForEmptyEventLoopをfalseに設定しても、DynamoDBへのすべての書き込みがそこに存在することがわかりました。 –

+0

DAXクライアントコードを調べていないと、私は言いませんでしたが、効率的な理由からイベントループが完全に空にならないように、ファイルハンドル(ネットワーク接続?)を開いている可能性があります。 –

+0

私は、何が起こっているのかを試してみるためにコードを深く掘り下げました(それは他の場所でも問題を引き起こしていました)。ソケット接続が完了したら、ソケット接続をクリーンアップしていないように見えます。 –

関連する問題