AWS lambda fonction des arrêts de travail après l'expiration du délai d'erreur

Question

J'ai une simple fonction lambda de façon asynchrone fait des appels d'API, puis renvoie les données. 99% du temps, cela fonctionne très bien. Quand jamais l'API prend plus de temps, puis le lambda configuré délai d'attente, il donne une erreur comme prévu. Maintenant la question est que lorsque je fais tous les appels suivants de la fonction lambda définitivement me donne l'erreur de dépassement de délai.

 "errorMessage": "2016-05-14T22:52:07.247Z {session} Task timed out after 3.00 seconds"

Afin de tester que c'était le cas, j'ai mis le lambda délai d'attente de 3 secondes et avoir un moyen de déclencher ces deux fonctions au sein de la lambda.

Javascript

function now() { 
    return response.tell('success'); 
}

function wait() {
    setTimeout(function() { return response.tell('success'); }, 4000);
}

Lorsque j'appelle l' now fonction il n'y a pas de problèmes. Lorsque j'appelle l' wait fonction j'obtiens l'erreur de dépassement de délai, puis tous les appels ultérieurs now de me donner la même erreur.

Est-ce un comportement normal? Je pense que tous les appels suivants de la fonction lambda devrait fonctionner. Je comprends que je peux toujours augmenter la configuration du délai d'expiration, mais serait plutôt de ne pas.

Answer 1

Vous devriez regarder pour comment votre fonction poignée fonctionne avec une context.callbackWaitsForEmptyEventLoop

Si ce type booléen est - false, le setTimeout ne sera jamais tiré, parce que vous avez peut-être répondu/manipulé le lambda invocation plus tôt. Mais si la valeur de callbackWaitsForEmptyEventLoop est true - puis votre code à faire ce que vous cherchez.

Aussi, il est probablement plus facile de tout gérer via des rappels directement, sans la nécessité d'une "écrit à la main" les délais d'attente, changer la configuration des délais d'attente et ainsi de suite...

E. g.

function doneFactory(cb) { // closure factory returning a callback function which knows about res (response)
  return function(err, res) {
    if (err) {
      return cb(JSON.stringify(err));
    }
    return cb(null, res);
  };
}

// you're going to call this Lambda function from your code
exports.handle = function(event, context, handleCallback) {

  // allows for using callbacks as finish/error-handlers
  context.callbackWaitsForEmptyEventLoop = false;

  doSomeAsyncWork(event, context, doneFactory(handleCallback));
};

Answer 2

eh bien, si vous avez défini les 3 secondes en fonction de votre configuration, ce délai sera de remplacer la fois à l'intérieur de votre code, donc assurez-vous d'augmenter le délai d'expiration de votre fonction lambda configs et essayez à nouveau le wait() et ça devrait fonctionner!

Answer 3

J'ai couru dans le même problème, en fait, il existe de nombreux cas où les Lambda ne répond plus, p. ex.:

1. L'analyse ne json valide:

   exports.handler = function(event, context, callback)
   {
       var nonValidJson = "Not even Json";
       var jsonParse = JSON.parse(nonValidJson);
   

2. Accès à la propriété de undefined variable:

   exports.handler = function(event, context, callback)
   {
       var emptyObject = {};
       var value = emptyObject.Item.Key;
   

3. Pas de fermeture de connexion mySql après l'accès RDS conduit à Lambda délai d'attente, puis il devient non-réactif.

Quand je dis ne répond pas c'est, littéralement, pas même de chargement, c'est à dire de la première impression à l'intérieur du gestionnaire n'est pas imprimé, et Lambda juste sorties de chaque course avec délai d'attente:

exports.handler = function(event, context, callback)
{
    console.log("Hello there");

C'est un bug, connu par équipe AWS pour près d'un an:
https://forums.aws.amazon.com/thread.jspa?threadID=238434&tstart=0

Malheureusement il n'est toujours pas résolu, après quelques tests, il est révélé que, en fait, Lambda essaie de redémarrer (recharger le conteneur?), il n'y a tout simplement pas assez de temps. Si vous définissez le délai à 10 ans, après ~4s de temps d'exécution Lambda commence à travailler, et puis, dans les prochaines descentes vient de se comporter normalement. J'ai aussi essayé de jouer avec le réglage:

context.callbackWaitsForEmptyEventLoop = false;

et mettre tous les "requiert" des blocs à l'intérieur de gestionnaire, rien n'a vraiment fonctionné. La seule façon de prévenir Lambda devenir des morts est le réglage plus grand délai d'attente, 10s devrait être plus que suffisant comme une solution de contournement de la protection contre ce bug.

Answer 4

Dans Amazon console AWS config vous devez modifier la valeur par défaut délai d'attente de 3 secondes de plus (5 min max)

Answer 5

J'ai juste eu à augmenter le délai d'attente et le message d'erreur est calmée. J'ai augmenté à 5 secondes. C'était bon pour moi car je n'étais pas va utiliser cette Lambda dans la production.