I'm new to Serverless (JAWS), so I might overlook something obvious here. I've a very simple test function that uses the mysql
node module, instantiates a connection pool, gets a connection and then releases it again:
var mysql = require ("mysql");
var config = {
// settings go here
};
module.exports.respond = function(event, cb) {
var pool = mysql.createPool({
connectionLimit: config.connectionLimit,
host: config.host,
user: config.user,
password: config.password,
multipleStatements: true
});
pool.getConnection(function(err, connection) {
err && console.log("Error establishing a database connection: ", err);
connection.release();
return cb(err, "Done.");
});
};
This function works perfectly fine when deployed to AWS, it exits within a few milliseconds and the world is bright and beautiful. However, running this function locally with serverless function run
, it will print "Done.
" at the end, but never exit.
I figured out that the reason probably is that I'm not releasing the mysql connection pool. If I change the last command in the above function to the following, then everything works:
pool.end(function() {
return cb(err, "Done.");
});
It _seems_ that Serverless is waiting for the mysql event loop to finish and wont exit unless that happens. However, to my understanding I should _not_ close the connection pool so future calls of the same Lambda function will be able to reuse the pool and thus won't require a new DB connection but reuse an existing one.
So is the behavior of Serverless expected here to block or is this a bug? I was under the impression that calling context.done()
would finish and return. So I would expect that Serverless exits when testing this locally.
I've just tested this with 0.1.0 and it still behaves the same way: Running the function locally (through sls function run component/module/func
) will hang and not return to command line, while the deployed Lambda function works as expected.
same issue here
For everybody still having this issue... I think it's arguable whether this is a bug or not. The reason sls
isn't shutting down is that there's still a loop running and the app is, at least in theory, still able to process additional requests (additional invokes of handler.handle()
). This is exactly the same behavior as you would see on Amazon's servers as well: The Lambda instance is kept running to process further requests and will be stopped (killed) at some point in future, when Amazon wants to free up resources. Any global variable will be retained across those invocations. If you have a MySQL connection pool then this pool will still be available for the next Lambda invocation, speeding things up noticeably.
So should Serverless exit the process when the function call completes or not? I don't know. But judging from @eahefnawy 's response to close this report, I assume the expected behavior is to keep running.
Most helpful comment
For everybody still having this issue... I think it's arguable whether this is a bug or not. The reason
sls
isn't shutting down is that there's still a loop running and the app is, at least in theory, still able to process additional requests (additional invokes ofhandler.handle()
). This is exactly the same behavior as you would see on Amazon's servers as well: The Lambda instance is kept running to process further requests and will be stopped (killed) at some point in future, when Amazon wants to free up resources. Any global variable will be retained across those invocations. If you have a MySQL connection pool then this pool will still be available for the next Lambda invocation, speeding things up noticeably.So should Serverless exit the process when the function call completes or not? I don't know. But judging from @eahefnawy 's response to close this report, I assume the expected behavior is to keep running.