I have a web request that can take 30-90 seconds to complete in some cases(most of the time it completed in 2-3). Currently, the software looks like it has hung if the request takes this long.
I was thinking that I could use background worker to process the webrequest in a separate thread. However, The software must wait on the request to process before continuing. I know how to setup the background worker. What I am unsure about is how to handle waiting on the request to process.
Do I need to create a timer to check for the results until the request times out or is processed?
I wouldn't use a timer. Rather, when the web request completes on the worker thread, use a call to the Invoke method on a control in the UI to update the UI with the result (or send some sort of notification).
Related
i can't understand why use Asynchronous and await when fetch data from server
A network request from a client to a server, possibly over a long distance and slow internet can take an eternity in CPU time scales.
If it weren't async, the UI would block until the request is completed.
With async execution the UI thread is free to update a progress bar or render other stuff while the framework or Operating System stack is busy on another thread to send and receive the request your code made.
Most other calls that reach out to the Operating System for files or other resources are async for the same reason, while not all of them are as slow as requests to a remote server, but often you can't know in advance if it will be fast enough to not hurt your frame rate and cause visible disruption or janks in the UI.
await is used to make code after that statement starting with wait is executed only when the async request is completed. async / await is used to make async code look more like sync code to make it easier to write and reason about.
Async helps a lot with scalability and responsiveness.
Using synchronous request blocks the client until a response has been received. As you increase concurrent users you basically have a thread per user. This can create a lot of idle time, and wasted computation. One request gets one response in the order received.
Using asynchronous requests allows the client to receive requests/send responses in any random order of execution, as they are able to be received/sent. This lets your threads work smarter.
Here's a pretty simple and solid resource from Mozilla:
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Asynchronous_request
I have an asynchronous controller,
I know the action will work asynchronously (no other action wait for that) and returns after completion of the task.
So my question is how it is deferent from making an asynchronous Ajax request to an action.
I think both are same in result.
An async request from javascript is not the same as an async task on the server.
An async task from javascript is still processed synchronously on the server, and as such, you may encounter thread pool starvation on large applications.
Having an async request that is processed asynchronously on the server is different, it frees up the IIS thread to immediately process other requests while that request, either from javascript or a full post/get is processed in the background.
some reading may help
http://msdn.microsoft.com/en-us/library/ee728598(v=vs.98).aspx#processing_asynchronous_requests
I have a high-rate UDP server using Netty (3.6.6-Final) but notice that the back-end servers can take 1 to 10 seconds to respond - i have no control over those, so cannot improve latency there.
What happens is that all handler worker threads are busy waiting for response and that any new request must wait to get processed, over time this response comes very late. Is it possible to discover for a given request that the thread pool is exhausted, so as to intercept the request early and issue a server busy response?
I would use an ExecutionHandler configured with an appropriate ThreadPoolExecutor, with a max thread count and a bounded task queue. By choosing differenr RejectedExecutionHandler policies, you can either catch the RejectedExecutionException to answer with a "server busy", or use a "caller runs policy", in which case the IO worker thread will execute the task and create a push back (but that is what you wanted to avoid).
Either way, an execution handler with a limited capacity is the way forward.
I am using sendAsynchronous request to receive data from multiple request at same time. It works great, i am able to load all the data. Even it is faster. But i want to cancel my request if the user cancels the request. so i have created a NSThread and using that thread i have created asynchronous request. When user clicks cancel button i just cancelled the thread.
But even after cancelling the thread the data is still getting loaded. So i want to stop those requests completely from loading data.
Even i used this,
[NSObject cancelPreviousPerformRequestsWithTarget:(id) selector:(selector) object:(id)]
but it doesn't work. Any help or suggestion will be appreciated.
Thanks in advance.
According to the documentation the NSUrlConnection class has it's own cancel method.
Note: Why are you using sendAsynchronousRequest in a own thread? The completion-handler will be executed when the request returns. While the request tries to reach the server and get an answer the main-thread shouldn't be blocked. I suggest to use either a synchronous request in a background thread or an asynchronous request in your main thread.
Also be aware, that your thread doesn't terminate just by calling [NSThread cancel]
Is it best to send a synchronous or an asynchronous request?
I'm sending a request to a server, asking for a list of files, which I would like the user to choose from.
Synchronous request does stop the application from any user action until it completes, because it runs in the main thread.
Asynchronous does not as it runs in other thread.
You should always use asynchronous requests as they do not block the thread they are called from. Instead they will call your delegate methods when the connection fails or succeeds. If you need to prevent the user from doing anything while the connection is running, use a HUD class like MBProgressHUD (check github).
You'd want to use asynchronous calls when you're calling from the Main Thread. Otherwise, the whole user interface will become unresponsive (i.e: freeze) until the server responds. (The user interface in maintained by the main thread).
You'd want to use synchronous calls when you're calling from another thread and you want it to wait until it has the response before continuing. If you've manually created a thread, calling asynchronous from this new thread would create a third thread.
Asynchronous means the "calling body" won't wait until the task is done.