2016-06-13 3 views
9

Я использую две функции лямбда с функцией выполнения Javascript 4.3. Я запускаю первый, и он вызывает второй синхронно (синхронизация - это намерение). Проблема - второй раз (60 секунд), но на самом деле он достигает успешного завершения всего за 22 секунды.Лямбда Время после вызова обратного вызова

Вот поток между двумя лямбда-функции:

flow

Lamda функция Я больше не получаю журналы CloudWatch для но реальная проблема (я думаю) является функция B которые раз без причины.

Вот некоторые журналы CloudWatch для иллюстрации этого:

cloudwatch logs

Код в функции B в конце - который включает в себя журнал заявление «Успех» видеть в рисунке выше - приведена ниже:

code example

Первоначально я имел только callback(null, 'successful ...') линию, а не nodejs 0.10.x путь, где под названием succeed() от о f контекст. В отчаянии я добавил оба, но результат тот же.

У кого-нибудь есть идея, что происходит? Любой способ, которым я могу отладить это?


В случае вызова логика между A и B делает разницу в состоянии, B начинается в, вот вызов:

invocation of Function b

+10

Я по-прежнему получаю винт Lambda + Node 4.3, но устанавливаю ['context.callbackWaitsForEmptyEventLoop = false;'] (https://aws.amazon.com/blogs/compute/ node-js-4-3-2-runtime-now-available-on-lambda /) может быть обходным путем для того, что вы видите, если оно похоже на то, с чем я столкнулся - у меня было соединение mysql, я не был отключение, которое, в свою очередь, удерживало цикл событий непустым. Установка значения, показанного на рисунке, показала проблему (путем «фиксации» прогона до таймаута); учитывая это доказательство, я смог правильно его решить, закрыв эту связь, после чего мне больше не нужен обходной путь. –

+0

Хорошо, я думаю, что это нить, за которой я могу следовать; забыл функциональное изменение того, что делает обратный вызов 4.3. Благодаря! Примечание. Я передал этот вопрос AWS, и они пришли, чтобы сказать, что у многих людей есть эта проблема, и что для многих возвратов к 0.10 решает проблему. Это сработало для меня, но, очевидно, это не отличное решение, так как это означает, что есть открытые соединения, которые я предпочитаю закрывать грациозно/контролируемым образом. – ken

ответ

16

Как Michael - sqlbot сказал; проблема заключается в том, что до тех пор, пока существует открытое соединение, из-за непустого цикла событий вызов вызывающего вызова не прерывает функцию. Имела ту же проблему с открытым соединением Redis; решение, как указано, context.callbackWaitsForEmptyEventLoop = false;

+0

Это работало ранее, но больше не работает. Я столкнулся с той же проблемой при подключении redis –

+0

Мне не удалось заставить это работать. Я также прочитал поток в узле mysql github, который, если вы начнете получать тайм-ауты, может потребоваться установить для этого значение true. – red6

Смежные вопросы