readme suggests done() which is incorrect
See original GitHub issueOn the readme, it says to call done();
Following this, 3 times I managed to exhaust all database connections. The link under the example suggests done(client);
which correctly closes the connection.
I think this is a possible documentation error.
Basically we need the connection timeout handler to live in a separate process to make the lambda function freezable. That should solve the termination timeout issue (in theory).
How lambda handles re-use is described here in detail: https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/ Pay attention to the last section in particular.
Issue Analytics
- State:
- Created 8 years ago
- Comments:22 (4 by maintainers)
Top Results From Across the Web
Incorrect documentation in README.txt [#1014154] | Drupal.org
I can confirm that #2 gets the job done. By the way, the project page should be updated to reflect this information- the...
Read more >Bundler using wrong ruby version · Issue #4260 - GitHub
It looks like you have both rbenv and rvm directories on your path. Are you using both of these? I'd suggest picking one...
Read more >ITM VIOS README CONTAINS STEPS INCORRECT ... - IBM
ITM VIOS Readme contains steps incorrect information for installation and upgrade of VIOS agent. The 6.1.0.1-TIV-ITM_VIOS_PREM-LA0001 Readme contains ...
Read more >github/git Checkout Returns 'error: invalid path' on Windows
I had not heard of core.protectNTFS doing this, but searching through the Git source code, there it is. The comment around it says...
Read more >init/README.md
The condition boot && property:true=true will be evaluated to false because the boot ... For native executables see libcutils android_get_control_file().
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Final Note for now: We stopped using connection pooling. Amazon handles this very badly. Basically we now always call
client.release(true)
to terminate any connection.This will be best practice until Amazon improves their container handling with Lambda. If you don’t do this you are dealing with all sorts of issues (one is that many open connections are just sticking around).
Yep, setting context.callbackWaitsForEmptyEventLoop = false; seems to resolve this.
Can you confirm @brianc ?