After looking at the AWS Lambda documentation and some stackoverflow questions (especially this one: Context vs Callback in AWS Lambda), I'm still a little confused what the purpose of callback or context.success() is. Also, what was the original reason behind having context.success() back when callback couldn't be used?
I'm asking because I was given a Lambda function that uses both calls, and I don't know why one was chosen over the other at a given point.
Thanks!
From this article:
Context.succeed [is] more than just bookkeeping – [it] cause[s] the
request to return after the current task completes and freeze[s] the
process immediately, even if other tasks remain in the Node.js event
loop... [On the other hand,] the callback waits for all the tasks
in the Node.js event loop to complete, just as it would if you ran
the function locally. If you chose to not use the callback parameter
in your code, then AWS Lambda implicitly calls it with a return value
of null. You can still use the Context methods to terminate the
function, but the callback approach of waiting for all tasks to
complete is more idiomatic to how Node.js behaves in general.*
Related
This question already has answers here:
Handling errors in Promise.all
(22 answers)
Closed 1 year ago.
I have a lambda which does multiple things in parallel (I call async functions and just wait for their Promise.all to be fulfilled before moving on).
The problem: as soon as one of these tasks fails and the async function throws, I want to be able to terminate the lambda and interrupt everything. Something like calling exit(-1). Is there any way to do this?
I don't want to report a failure then have cloudformation do a ROLLBACK (therefore calling my lambda with the event Delete), start deleting/rollbacking stuff and maybe the other async functions were still doing their Create event therefore making a terrible mess. I looked at the CloudWatch logs and it seems that this mess is a totally plausible scenario.
Cause you mentioned Promise.all, I assume you have a JavaScript lambda function.
You cannot kill or terminate a lambda function. The engine used (in this case JavaScript), needs to finish all of its executions. You basically need to solve this on the code level and as I understand you want to cancel all other async functions when one throws an error.
You can check answers here or here to better understand what you can do to cancel other promises when one in Promise.all fails. In short, you need to use third-party libraries and wrap some of the code you do not want to continue executing into additional functions chained after the code which can fail.
You also need to figure out what you want to do with non-blocked IO operations (e.g. canceling database transactions) and this depends on the specific operations you execute in your code.
To further alleviate the mess you can check this answer and set lambda function concurrency limit to 0 or create separate lambda functions for each of your async operations and orchestrate them with AWS Step Function.
As per my knowledge, A callback is a function which is called when a task is completed, thus helps in preventing any kind of blocking and a callback function allows other code to run in the meantime. Callback is called when task get completed and is asynchronous equivalent for a function.
But, i am not able to implement in real time, can anyone here can help me to how to write a call back function for simple app.js application? and i need to know how to call a function.
Kind of a weird question, Imagine you have a situation where you need to run 10 SYNCRONOUS functions, it doesn't matter when they complete, you just want to know when all 10 are done: I.E.
f1()
f2()
f3()
...
f10()
doStuffWithResult();
Now, If you use promises like so, assuming you have rewrote each as promoises:
Promise.All([f1,f2,f3,f4,f5,f6,f7,f8,f9,f10])
.then(() => {
doStuffWithResult();
})
Would you see a performance increase? Theoretically, I want to say no because these functions are still synchronous, and everything is still running on one thread.
Thanks!
Would you see a performance increase?
No, what you are proposing would not be faster.
Promises do not create threads. All they do is provide a cooperative system for keeping track of when asynchronous operations are complete and then notifying interested parties of success or failure. They also provide services for propagating errors when asynchronous operations are nested.
And, your proposed Promise.all() code would not even work. You must pass an array of promises to Promise.all(), not an array of function references. In your example, your functions would not even be called.
And, if you changed your code to something that would actually execute, then it would likely be slower than just calling the synchronous functions directly because you'd be executing promise code and all .then() handlers execute on a future tick (not synchronously).
In node.js, the only way to execute synchronous things in parallel is to launch child processes (that can execute in parallel) or pass the operations to some native code that can use actual OS threads.
I'm just starting with c# development, and i always strugled with asyncronous programming,Ii have a doubt about performing a task asyncrounously.
I have my own service capable of sending an email (not going into details but its working) and I want that the execution of that method runs asyncronously, I've been reading in msdn documentation about async and await.
I do want to send it asyncronously but i dont care about the result, I mean I dont want to specify an await statement. I was about to try it whithout it when I read from documentation
If an async method doesn’t use an await operator to mark a suspension point, the method executes as a synchronous method does, despite the async modifier.
So mi doubt would be, is that so? is there a way to achieve what I am looking for or it is a bad pactice/idea thinking in doing something like that. I hope i made my self clear. Thanks
Regarding what you read in the docs, think about this this way:
public async Task OuterMethod()
{
InnerMethod();
}
You've marked OuterMethod async, yet you're not doing any awaiting. The docs are simply saying that OuterMethod will run synchronously, and you may as well just mark it with void instead of async Task. However, the fact that OuterMethod runs synchronously doesn't change the nature of InnerMethod; it may well be asynchronous, and if you're not awaiting it, it will run fire-and-forget style, most likely on a background thread.
In your specific case, InnerMethod would be the method that sends the email. If you're certain you don't care whether sending the email succeeds or fails, I'd suggest calling SmtpClient.SendAsync without awaiting.
In chrome API for extensions lots of methods take "callback" argument. But for majority of methods it's not documented when callbacks are called. For example, chrome.tabs.remove takes callback that reads:
If you specify the callback parameter, it should specify a function that looks like this:
function() {...};
This is all documentation i have. Given this documentation, how can i figure if callback will be called only once after all tabs are removed, or after each tab is removed? Based on the answer, i need to write different code. Maybe it's some "general" documentation sections about callback in chrome API, like "callbacks are always called once after operation is complete if otherwise is not specified". Or no one uses this API and no one cares about documentation?
From the Overview page:
Most methods in the chrome.* APIs are asynchronous: they return immediately, without waiting for the operation to finish. If you need to know the outcome of that operation, then you pass a callback function into the method.
The implied information here is that callbacks are called when information about the completed operation is available to be passed to the callback. When that is and exactly what information is available varies from operation to operation.
Callbacks are called once all of the relevant work has been done, so the tabs.remove callback is called once all specified tabs are closed.