I have some doubt in Asynchronous and synchronous terms in ajax.
How Asynchronous process will work?
Can you please let us know about this terms?
Synchronous ( async: false ) – Script stops and waits for the server to send back a reply before continuing.
Asynchronous ( async: true ) – Async requests occur on a background thread, meaning that the UI is not going to be blocked while the request is processing.
Why AJAX has called Asynchronous? Can you please describe any one
please?
asynchronous is the best because the client and the server run independently of each other for the duration of the function call.
During a normal function call, you make the call, and the calling function doesn't get to execute again until the function call finishes and returns. The caller and the callee are always synchronized.
During an asynchronous function call, you make the call, and then control returns immediately to the caller. The callee then returns a value some indeterminate amount of time later. That "indeterminate amount of time" means the caller and callee are no longer synchronized, so it's asynchronous.
Meanwhile you can make multiple request if you set async:true because control returns immediately, it will not wait like synchronous call till it receives response from server, here is picture which give clear idea.
Related
I'm writing a slack bot with Go and Aws Lambda. Slack requires for the bot to reply within 3 seconds. However, sometimes I can't make it reply that fast, cuz it's "talking" to other serverless applications for requesting some data or dispatching tasks. I have never worked with goroutines before, but I was hoping that I could implement something like this:
Lambda receives a request
The bot creates a goroutine that will process this request and act accordingly on it
The handler doesn't wait for all these actions to complete but replies right away with 200.
Lambda continues to run until goroutine is finished.
I'm not sure if that's even possible.
I've read about sync.WaitGroup, but I'm not sure how to incorporate it together with main function. Should I use it inside the handler? But I need to return response and that's not a function that I can wrap into a goroutine.
Ideally, I would like for handler to reply right away and then process goroutine in the background.
Don't try to do anything in your lambda handler after the request finishes.
A more reliable approach:
Accept the call and record whatever input data is needed.
Put the data in SQS
Respond with HTTP 200
Another (SQS triggered) function does the processing and if needed, calls Slack back on recorded response_url
When my site first initializes, it queries a server to get back some data. I can't lay anything out on the page until this data gets back. With d3.js, I can use d3.json() to get my data, but because it's asynchronous, I need to put the entire page logic in the callback function. How do I request the data and wait for it to come back?
You're basically doing it the only way. The callback function has to be the one initiating the rest of your code. You don't need all your code in the callback function though, you can introduce indirection. So the callback function will call another function inside which would be what is currently in your callback function.
Using synchronous requests in JavaScript is not recommended as it blocks the whole thread and nothing gets done in the meantime. The user can also not interact well with the webpage.
If it is really what you want, you can do the following (using jQuery):
var jsonData;
jQuery.ajax({
dataType: "json",
url: "jsondatafile.json",
async: false
success: function(data){jsonData = data}
});
However it is not recommended, even by jQuery, as explained here the jQuery.ajax() documentation:
The first letter in Ajax stands for "asynchronous," meaning that the operation occurs in parallel and the order of completion is not guaranteed. The async option to $.ajax() defaults to true, indicating that code execution can continue after the request is made. Setting this option to false (and thus making the call no longer asynchronous) is strongly discouraged, as it can cause the browser to become unresponsive.
As a final note, I don't see what prevents you from using whatever function there is in the success attribute in an asynchronous way. Most of the times changing your design to use async requests will be worth it. By experience, debugging a page that uses synchronous requests is a pain (especially when the requests don't get answered...).
I'm using WinHTTP in sync mode, without passing the WINHTTP_FLAG_ASYNC flag, and I thought that the callback is always being called synchronously. That is indeed what's happening most of the time, but sometimes, when calling WinHttpCloseHandle, the callback isn't called with the WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING notification right away. Instead, it's being called afterwards from a different thread.
It that expected behavior? Why does it become async for some cases, if the seesion is sync? I know how to fix it (waiting for the WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING notification if I don't get it right away), but I don't understand why that's the behavior that I'm seeing.
WinHTTP does not promise synchronous "same thread" callbacks in synchronous mode. On the contrary, MSDN states the opposite:
The callback function must be threadsafe and reentrant because it can be called on another thread for a separate request, and reentered on the same thread for the current request. It must therefore be coded to handle reentrance safely while processing. When the dwInternetStatus parameter is equal to WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING, the callback does not need to be able to handle reentrance for the same request, because this callback is guaranteed to be the last, and does not occur when other messages for this request are handled.
This means that the symptom you are seeing is basically behavior by design and is not related to async mode: some callback calls might be sent to you from worker threads and then thread racing might reach your code late in your callback. You need to take this into consideration and either ignore those late calls, or synchronize with them, or reset callbacks early enough explicitly to not receive late notifications.
Regarding WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING specifically MSDN explains what you can rely on exactly (see quote above).
Say first I call async_connect on a newly constructed tcp::socket. Before the handler of async_connect is called, I call async_read/writes on the same socket. Will them wait for the connection or fail immediately because the socket has not connected?
Since async_connect performs asynchronously, your scenario has race-condition - so it may occasionally work or fail, depending on timings. In order to begin async. i/o on a socket, one should wait first for async_connect completion handler - just like described in the Asio documentation.
That's said, you can design a class that will accept async. operations as functors, store them in a queue, and internally chain/invoke them in the correct order.
I want to know the difference between setInterval() (or) setTimeout() in DOM and polling in ajax. What is the main difference? If both are same, why the identified by two different names?
What is mean by polling in AJAX?
Any links or resource about this question would be more appreciative at the moment!!!
setInterval sets a repeating timer, setTimeout sets a timer that fires only once. Polling is when you repeatedly ask for something instead of waiting to be notified. Sometimes polling is necessary, for example if there's no way to be notified -- and this is often the case in Ajax applications. Both setInterval and setTimeout can be used to implement polling, depending on what you want to do.
In the case of periodically making a request to a server it's advisable to use setTimeout instead of setInterval. In the callback you do the request, wait for the response then set a new timer using setTimeout. If you use setInterval and the request latency is comparable to the interval then you risk that the responses will come out of order. For example, the timer fires and you make a request, it takes a little longer than usual so before it has returned the timer fires again, so you make a new request. Now you are waiting for two requests. It would have been better to wait for the first request to come back before doing the second.
polling is when you periodically ping the server to see if something is ready. A user might have made a request that will take some unspecified amount of time, but too long to wait, so you poll the server every x seconds to see if the result is ready.
setTimeout executes a function after the specified interval.
setInterval repeatedly executes a function every time.
check out http://www.w3schools.com/js/js_timing.asp
You can use these two functions to implement a polling scheme, but they are definitely not the same as polling.