I have a situation where I am making an async call to a method that returns and IDisposable instance. For example:
HttpResponseMessage response = await httpClient.GetAsync(new Uri("http://www.google.com"));
Now before async was on the scene, when working with an IDisposable instance, this call and code that used the "response" variable would be wrapped in a using statement.
My question is whether that is still the correct approach when the async keyword is thrown in the mix? Even though the code compiles, will the using statement still work as expected in both the examples below?
Example 1
using(HttpResponseMessage response = await httpClient.GetAsync(new Uri("http://www.google.com")))
{
// Do something with the response
return true;
}
Example 2
using(HttpResponseMessage response = await httpClient.GetAsync(new Uri("http://www.google.com")))
{
await this.responseLogger.LogResponseAsync(response);
return true;
}
Yes, that should be fine.
In the first case, you're really saying:
Asynchronously wait until we can get the response
Use it and dispose of it immediately
In the second case, you're saying:
Asynchronously wait until we can get the response
Asynchronously wait until we've logged the response
Dispose of the response
A using statement in an async method is "odd" in that the Dispose call may execute in a different thread to the one which acquired the resource (depending on synchronization context etc) but it will still happen... assuming the thing you're waiting for ever shows up or fail, of course. (Just like you won't end up calling Dispose in non-async code if your using statement contains a call to a method which never returns.)
Related
In this code snippet:
responseMessage = await HttpClient.SendAsync(requestMessage);
The program ends execution (with exit code 0) as if nothing wrong happened, without continuing from that line. However, from my understanding of await, it should basically block until the method returned the HttpResponseMessage and then continue sequentially.
This code snippet below seems to do what I thought the top one did:
Task<HttpResponseMessage> sendAsyncTask = HttpClient.SendAsync(requestMessage);
sendAsyncTask.Wait();
responseMessage = sendAsyncTask.Result;
Why is this the case? What is wrong with the first code snippet?
The program ends execution (with exit code 0) as if nothing wrong happened, without continuing from that line.
Most likely, your Main method (or some other method in-between Main and this one) calls an asynchronous method and then ignores the returned task instead of awaiting it. Or you have an async void somewhere.
However, from my understanding of await, it should basically block until the method returned the HttpResponseMessage and then continue sequentially.
The entire point of await is that it doesn't block the caller. await does "pause" the method so it can "resume" later, but await also returns to its caller while the task is in progress. If the caller then exits the application (e.g., by exiting Main), then the method never gets a chance to resume because the application is torn down.
Picture the following code:
var client = new HttpClient();
var response = await client.GetAsync("www.someaddress.yo");
string content = await response.Content.ReadAsStringAsync();
Is there any added benefit, other than possibly saving a single thread, by writing the above code the following way:
var client = new HttpClient();
string content = await client.GetAsync("www.someaddress.yo")
.ContinueWith(r => r.Result.Content.ReadAsStringAsync()).Result;
Correct me if I'm wrong, but I believe performance-wise both codes end up doing the same amount of work.
The second snippet has no benefits, doesn't "save" any threads while allocating another task object and making debugging and exception handling harder by wrapping any exceptions in an AggregateException.
A task is a promise that something will produce some output in the future. That something may be :
A background operation running on a threadpool thread
A network/IO operation that doesn't run on any thread, waiting instead for the Network/IO driver to signal that the IO has finished.
A timer that signals a task after an interval. No kind of execution here.
A TaskCompletionSource that gets signalled after some time. No execution here either
HttpClient.GetAsync, HttpClient.GetStringAsync or Content.ReadAsStringAsync are such IO operations.
await doesn't make anything run asynchronously. It only awaits already executing tasks to complete without blocking.
Nothing is gained by using ContinueWith the way the second snippet does. This code simply allocates another task to wrap the task returned by ReadAsStringAsync. .Result returns the original task.
Should that method fail though, .Result will throw an AggregateException containing the original exception - or is it an AggregateException containing an AggregateException containing the original? I don't want to find out. Might as well have used Unwrap(). Finally, everything is still awaited.
The only difference is that the first snippet returns in the original synchronization context after each await. In a desktop application, that would be the UI. In many cases you want that - this allows you to update the UI with the response without any kind of marshalling. You can just write
var response = await client.GetAsync("www.someaddress.yo");
string content = await response.Content.ReadAsStringAsync();
textBox1.Text=content;
In other cases you may not want that, eg a library writer doesn't want the library to affect the client application. That's where ConfigureAwait(false) comes in :
var response = await client.GetAsync("www.someaddress.yo").ConfigureAwait(false);
string content = await response.Content.ReadAsStringAsync().ConfigureAwait(false);
I call this getJson() function from an async action in my controller.
I have a list of large files that each take a few seconds for ReadToEndAsync() to process.
The ReadToEndAsync() is blocking even though I'm awaiting it.
How can I call ReadToEndAsync() asynchronously?
public static async Task<T> getJson<T>(String url)
{
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(server + url);
HttpWebResponse response = (HttpWebResponse)await request.GetResponseAsync();
String jsonString;
//get the json string from the response
using (var xx = response.GetResponseStream())
{
StreamReader reader = new StreamReader(xx, Encoding.UTF8);
jsonString = await reader.ReadToEndAsync()
}
}
Controller:
_model.list.Add(await DataRetriever.getJson<ReviewModel>(url));
_model.list.Add(await DataRetriever.getJson<ReviewModel>(url));
_model.list.Add(await DataRetriever.getJson<ReviewModel>(url));
As noted in the comments, while the method ReadToEndAsync() does not block per se – in the usual sense of the word "block": that is, the thread that calls that method continues to run – it certainly will prevent the code after the await from executing until the method has completed. Which is exactly what you want: you don't want that code to execute until the read has completed, otherwise it wouldn't have the result to operate on.
You should probably (re?)read the documentation on async and await, but briefly: the keyword async is applied to a method to signal to the compiler that it will use await. The await is used to indicate to the compiler a point in the method where the compiler should save the current execution state of the method and return.
If and when the operation to which the await keyword has been applied completes, the framework will automatically continue execution of the method where it left off. Where the method is called in a thread that is tied to a synchronization context (e.g. a GUI thread in a Winforms or WPF program), by default this "continuation" is executed in that original thread (but this can be disabled when appropriate).
Please note above that the async method returns from await statements. Thus, the method itself does not block the thread, even as the operation represented by the method does "block" in some sense of the word.
So, with that all said, it seems to me that you may be trying to get your three operations to all complete asynchronously and concurrently. If you want to do that, you need to start all of the asynchronous operations at once, rather than waiting for each to complete before proceeding to the next as you do now (i.e. via the await statement applied to the call to the getJason<T>() method).
That would look something like this:
Task<ReviewModel> task1 = DataRetriever.getJson<ReviewModel>(url1),
task2 = DataRetriever.getJson<ReviewModel>(url2),
task3 = DataRetriever.getJson<ReviewModel>(url3);
_model.list.Add(await task1);
_model.list.Add(await task2);
_model.list.Add(await task3);
(Note: in your original code example, you only used a single url value. Since I assume you don't really want to just execute the same query three different times, I went ahead and changed the code example so that each task uses a different value).
In the above, even if the second and/or third task completes before the first, the results will be added to the result list in order. But the tasks themselves are started all at the same time so that they can run concurrently.
I hope that the above not only clarifies for you whether or not the call to the method ReadToEndAsync() is blocking (it does not, though because of the way the debugger presents the execution of your code, it might seem that it does), but also provides you with the solution to the larger problem that led you to debug the method and think that it's blocking. I.e. that your JSON queries didn't execute concurrently.
If between the comments on your question, and the above answer, you still have a problem, please edit your question so that it's more clear about what exactly you are asking.
Lets say im within an ASP.NET application, WCF or web API, part of this applications job to is contact a 3rd party over the way. Id like to do this asynchronously or rather non blocking so that the thread pool doesnt get starved. However i dont want to change all my code in the service only the bit that makes the web call.
Here is some code i have written:
public string GetSomeData()
{
Task<string> stuff = CallApiAsync();
return stuff.result; //does this block here?
}
private async Task<string> CallApiasync()
{
using (var httpClient = new HttpClient())
{
string response = await httpClient.GetStringAsync(Util.EndPoint).ConfigureAwait(false);
return response;
}
}
I thought the idea was as follows but please correct any misconceptions.
The caller of CallApi can call the method and when it hits await there is a Task created which represents some work to be done asynchronously but that will take some time. At this point the thread reaches an await returns to the thread pool to do something else ie handle a different request. Once the Task completes the await line wakes up and the code continues from there as if it was synchronous.
If this is the case why do i need to return a Task from my apimethod. The caller seems to have to call stuff.Result which implies that the task may not have finished and calling result could block ? Note i don't want to make the calling method async too as then the method that calls that would need to be async etc etc.
What is the order of event here in my code?
One other question is why did i need to set configureAwait to false? otherwise everything hangs.
Id like to do this asynchronously or rather non blocking so that the thread pool doesnt get starved. However i dont want to change all my code in the service only the bit that makes the web call.
That's not possible. In order to be truly asynchronous, you must allow async to "grow" through the code as far as it needs to. What you're trying to do is block on an asynchronous call, which won't give you any benefit (you're freeing up a thread by using async, but then you're turning around and consuming a thread by using Result).
At this point the thread reaches an await returns to the thread pool to do something else ie handle a different request.
Not quite. When an async method hits an await, it returns an incomplete Task to its caller. If the caller, in turn, awaits that task, then it returns an incomplete Task to its caller, etc. When the ASP.NET runtime receives an incomplete Task from your action/service method/whatever, then it releases the thread to the thread pool.
So, you do have to go "async all the way" to see the real benefit of async.
I have an async intro on my blog if you want a more gentle introduction, as well as an MSDN article on async best practices (one of which is: async all the way). I also have a blog post that describes the deadlock you were seeing.
The compiler handles a lot of the magic behind the async pattern for you, but syntactically, you have to tell it what you want it to do by providing a method prototype that says "ok, this is an asynchronous operation that can be awaited."
For this to happen, your method must return a Task or Task<T>.
Any Task can be awaited.
You should be VERY careful when using .Result and .Wait(), as they can block in some very unexpected circumstances, because the runtime may decide to execute your method synchronously.
You should say:
await CallApiAsync();
or, to actually take advantage of it:
Task stuff = CallApiAsync();
//More code that can happen independetly of "stuff"
await stuff;
In order to do that, your GetSomeData() function must also be marked as async, but it doesn't have to, itself, return a Task.
Finished copy of a working async version of your code:
public async string GetSomeData()
{
Task stuff = CallApiAsync();
return await stuff;
}
private async Task<string> CallApiasync()
{
using (var httpClient = new HttpClient())
{
string response = await httpClient.GetStringAsync(Util.EndPoint).ConfigureAwait(false);
return response;
}
}
Honestly, if that's all the CallApiAsync function is ever going to do, you may as well inline it, though.
I have a call I am making from inside a xaml-based, C# metro application on the Win8 CP; this call simply hits a web service and returns JSON data.
HttpMessageHandler handler = new HttpClientHandler();
HttpClient httpClient = new HttpClient(handler);
httpClient.BaseAddress = new Uri("http://192.168.1.101/api/");
var result = await httpClient.GetStreamAsync("weeklyplan");
DataContractJsonSerializer ser = new DataContractJsonSerializer(typeof(WeeklyPlanData[]));
return (WeeklyPlanData[])ser.ReadObject(result);
It hangs at the await but the http call actually returns almost immediately (confirmed through fiddler); it is as if the await is ignored and it just hangs there.
Before you ask - YES - the Private Network capability is turned on.
Any ideas why this would hang?
Check out this answer to my question which seems to be very similar.
Something to try: call ConfigureAwait(false) on the Task returned by GetStreamAsync(). E.g.
var result = await httpClient.GetStreamAsync("weeklyplan")
.ConfigureAwait(continueOnCapturedContext:false);
Whether or not this is useful depends on how your code above is being called - in my case calling the async method using Task.GetAwaiter().GetResult() caused the code to hang.
This is because GetResult() blocks the current thread until the Task completes. When the task does complete it attempts to re-enter the thread context in which it was started but cannot because there is already a thread in that context, which is blocked by the call to GetResult()... deadlock!
This MSDN post goes into a bit of detail on how .NET synchronizes parallel threads - and the answer given to my own question gives some best practices.
Just a heads up - if you miss the await at the top level in an ASP.NET controller, and you return the task instead of the result as a response, it actually just hangs in the nested await call(s) with no errors. A silly mistake, but had I seen this post it might have saved me some time checking through the code for something odd.
Disclaimer: I don't like the ConfigureAwait() solution because I find it non-intuitive and hard to remember. Instead I came to the conclusion to wrap non awaited method calls in Task.Run(() => myAsyncMethodNotUsingAwait()). This seems to work 100% but might just be a race condition!? I'm not so sure what is going on to be honest. This conclusion might be wrong and I risk my StackOverflow points here to hopefully learn from the comments :-P. Please do read them!
I just had the problem as described and found more info here.
The statement is: "you can't call an asynchronous method"
await asyncmethod2()
from a method that blocks
myAsyncMethod().Result
In my case I couldn't change the calling method and it wasn't async. But I didn't actually care about the result. As I remember it also didn't work removing the .Result and have the await missing.
So I did this:
public void Configure()
{
var data = "my data";
Task.Run(() => NotifyApi(data));
}
private async Task NotifyApi(bool data)
{
var toSend = new StringContent(JsonConvert.SerializeObject(data), Encoding.UTF8, "application/json");
await client.PostAsync("http://...", data);
}
In my case I didn't care about the result in the calling non-async method but I guess that is quite common in this use case. You can use the result in the calling async method.