Im quite new to writing controllers for asp.net and Im trying to return IQueryable, but I cant seem to get the call for the content to return.
This is my controller:
// GET: api/RumsaRooms
[EnableQuery]
public IQueryable<RumsaRoom> GetRooms()
{
return db.Rooms;
}
and this is my client call:
public async Task<IQueryable<T>> GetAllOf<T>()
{
var typeName = typeof(T).Name;
var result = await _client.GetAsync($"api/{typeName}");
if (!result.IsSuccessStatusCode)
{
var exception = await result.Content.ReadAsStringAsync();
}
//This method never returns
var rooms = await result.Content.ReadAsAsync<IQueryable<T>>();
return rooms;
}
I have enabled multipleactiveresultsets in the connectionstring.
The StatusCode is 200.
The method that GetAllOf() looks like this:
private async Task<bool> LoadEntities()
{
var rooms = (await _rumsaClient.GetAllOf<RumsaRoom>()).ToList();
RoomsCollection = new ObservableCollection<RumsaRoom>(rooms);
return true;
}
LoadAllEntities is called in the constructor of my viewmodel.
If I change the call to this it works:
var rooms = await result.Content.ReadAsAsync<List<T>>();
Is it not possible to ReadAsAsync to a IQueryable?
Thanks
Erik
Your problem is almost certainly in this code:
LoadAllEntities is called in the constructor of my viewmodel.
I explain why this deadlock happens in detail on my blog. It doesn't have anything to do with ReadAsAsync or IQueryable. It has to do with calling Wait or Result on an asynchronous task.
In summary:
Tasks returned by async methods are only completed when that method completes.
await by default captures a "context" and uses that "context" to resume the async method.
On ASP.NET, this "context" is an instance of AspNetSynchronizationContext, which only allows one thread in at a time.
When the code calls Wait/Result, it will block the thread (which is still in the ASP.NET request context), waiting for the task to complete.
When the await is ready to resume the method, it does so in the captured context, and waits for the context to be free.
Since await cannot complete the method until the context is free, and the context is in use by a thread waiting until the method completes, you end up with a deadlock.
The proper way to solve this is to not block on asynchronous code; use await instead. This principle is called "async all the way", and is described in my MSDN article on async best practices. Since you're trying to call asynchronous code from a constructor, you may also find my blog post on async constructors helpful, which explains some alternative approaches.
Related
This question already has answers here:
What does await do in this function?
(3 answers)
Closed 2 years ago.
What is the purpose of the await keyword in the following code?
Does it create new thread for PostAsync function and then wait until that thread completes to return the await result?
Or does it not wait?
In the code below, would it be possible for Pins.Add function to execute before the firebase.PostAsync call is completed?
public async Task AddData(int id, string description, DateTime postdate, string usernames)
{
await firebase
.Child("Entries")
.PostAsync(new Entry() { id = id, description = description, postdate = postdate, username = username });
}
public MapPage()
{
AddData(1, result, DateTime.Now, deviceId);
customMap.Pins.Add(new CustomPin
{
..//
});
}
I cannot remove the async keyword from definition from AddData, so if this is incorrect, how would I fix this? The other option is to remove both keywords, would this still work with FireBase PostAsync call?
public void AddData(int id, string description, DateTime postdate, string usernames)
{
firebase
.Child("Entries")
.PostAsync(new Entry() { id = id, description = description, postdate = postdate, username = username });
}
What is the purpose of the await keyword in the following code?
It conceptually pauses the execution of the current method, until the awaited-thing completes.
Does it create new thread for PostAsync function and then wait until that thread completes to return the await result?
No, await itself does not create any new threads, and it does not really wait. It just looks like it does.
Or does it not wait?
Yes, it does not cause the thread to wait in the 'does it block?' sense. However, execution of the rest of 'AddData' method is paused. Yes, I've said 'AddData'. Execution of 'MapPage' is not affected. That may be a bug in your code (explained below).
In the code below, would it be possible for Pins.Add function to execute before the firebase.PostAsync call is completed?
Yes it certainly is.
I cannot remove the async keyword from definition from AddData, so if this is incorrect, how would I fix this?
AddData needs to be marked as async and needs to return a Task because its implementation uses await keyword. Using the await keyword is not a must. You may handle the Task returned by PostAsync in some other way. But when using await keyword, you MUST be in async-marked-Task-returning method.
If by "fix this" you mean you're concerned that Pins.Add should not execute before PostAsync completes, then you have to propagate the async-await pattern and make the MapPage "wait" for the result of AddData:
public async Task MapPage()
{
await AddData(1, result, DateTime.Now, deviceId);
customMap.Pins.Add(new CustomPin
{
..//
});
}
That's the bare minimum to answer your questions, but I think you may find a few more notes helpful.
As you may have noticed, if you HAVE to await the AddData, then it may mean that the caller of MapPage will have to await the MapPage as well. And so on. Maybe somewhere up above the call stack you will have the freedom to not await or to work around it in some way. But in general, it propagates up the call chain. Like an exception. It's not one of course, but think of it: if your current method has to "wait for something" then the method above.. ..probably has to be able to as well. At least if it wants to know the result of your current method - it has to wait until your current method actually produces that result, right? So it has to propagate as long as the result is important to the caller.
To explain how that happens: await splits the code in half, and POSTPONES the other half.
public async Task AddData(...)
{
await firebase
....
.PostAsync(...);
int x = 5;
}
becomes something like:
public async Task AddData(...)
{
Task tmp = firebase
....
.PostAsync(...);
Task continued = tmp.ContinueWith( continuation );
return continued;
}
private .. continuation()
{
int x = 5;
}
Note how there's no wait/sleep/etc. However, the int x=5 is delayed, until the original task returned from PostAsync notifies everyone that it has just completed.
Note how original task from firebase gets a 'continuation' chained to it, but a different task is returned: the continuation-task.
This means that the await (if you add it there of course) in MapData awaits not for just the firebase task, but for firebasetask+contination.
If there were more awaits in the AddData method, there would be more slices, more chained continuations, but the task that is eventually returned to the caller covers it all.
Now, any awaits in the MapData would do the same: it would split the code, register a continuation, and return the resulting task for someone to observe it.
The caller will get a Task again. But the caller doesn't realy HAVE TO await it. The called may run a thread that will await for the task. The caller may attach a continuation. Or put the task onto some queue and hand it off for someone else to handle. I mean that the async/await look like 'contagious disease' that always propagates upwards, but you can stop at any time it if you really need.
Also, as you already noted, the caller of AddData does not have to await that task, if the caller is not worried about the order of operations further down in the code. If the Pins.Add is allowed to run before firebase task completes, it's fine to not await for AddData. That's why not-awaiting an async method is not a compilation error. You will probably get a warning though, because the AddData returns a Task and that Task is ignored (not awaited, not stored, not chained .ContinueWith etc).
This should work...
public async Task MapPage()
{
Task t = AddData(1, result, DateTime.Now, deviceId);
await t;
customMap.Pins.Add(new CustomPin
{
..//
});
}
Continuation...
Mi Po follow up question::
would this also work as a solution?
public async Task MapPage()
{
await AddData(1, result, DateTime.Now, deviceId);
customMap.Pins.Add(new CustomPin { ..// });
}
Yes it would work...but in your particular case your doing an http post and you need (IMO) to check the result (status code) to determine what to do next. Something along these lines...
public async Task MapPage()
{
HttpResponseMessage result = await AddData(1, result, DateTime.Now, deviceId);
if (result.IsSuccessStatusCode)
{
customMap.Pins.Add(new CustomPin { ... });
}
else
{
...
}
}
You would also need to change AddData to return the responce
(Edited to add more detail about every call I'm making)
I have a Xamarin Forms application connecting to a .Net Core 2.2 web service hosted in Azure App Services.
In my view model I have a call like this:
private async Task GetItems() {
var result = await itemsListFactory.GetItemsAsync()
}
Which calls this:
public async Task<IEnumerable<IItemInfo>> GetItemsAsync() {
return await ItemList.GetItemListAsync();
}
Which calls this (CSLA business object):
public static async Task<ItemList> GetItemListAsync() {
return await DataPortal.FetchAsync<ItemList>();
}
Which calls this:
[Fetch]
private async void DataPortal_Fetch() {
var rlce = RaiseListChangedEvents;
RaiseListChangedEvents = false;
IsReadOnly = false;
using (var ctx = Dal.DalFactory.GetManager()) {
var dal = ctx.GetProvider<IItemDal>();
List<ItemDto> list = null;
list = await dal.FetchAsync();
foreach (var item in list) {
Add(DataPortal.FetchChild<ItemInfo>(item));
}
}
IsReadOnly = true;
RaiseListChangedEvents = rlce;
}
Which calls:
public async Task<List<ItemDto>> FetchAsync() {
var resultSet = new List<ItemDto>();
var connectionManager = ServiceLocator.Current.GetInstance<IAzureConnectionManager>();
using (var conn = await connectionManager.GetOpenConnectionAsync()) {
/* Reading from DB */
}
return resultSet;
}
The implementation of the AzureConnectionManager looks like this:
public async Task<SqlConnection> GetOpenConnectionAsync()
{
var accessToken = await new AzureServiceTokenProvider().GetAccessTokenAsync("https://database.windows.net/");
var connection = new SqlConnection(dbconnection) {
AccessToken = accessToken
};
await connection.OpenAsync();
return connection;
}
However, the first time I make this call (e.g. first call of the day, or after not using the service for a while) I get no results back. Any subsequent calls seem to work just fine. My guess is this has something to do with the service having to take a few "extra steps" to return data due to inactivity.
This suspicion seems to be confirmed whenever I debug the web service and set breakpoints in my view model as well as the server-side code. Whenever the service's call returns with no records it's almost as if it's returning early from the server, because it returns to the view model with no data, and then my debugger hops back onto the server after it's received the access token. So, it's as if my code decided not to wait for the GetAccessTokenAsync and OpenAsync to finish what they had to do before returning to the client.
I can fix this by adding a .Result to GetAccessTokenAsync() and .Wait() to OpenAsync() like this:
public async Task<SqlConnection> GetOpenConnectionAsync()
{
var accessToken = new AzureServiceTokenProvider().GetAccessTokenAsync("https://database.windows.net/").Result;
var connection = new SqlConnection(dbconnection) {
AccessToken = accessToken
};
connection.OpenAsync().Wait();
return connection;
}
But this feels like a hack.
I doubt this is the way I'm supposed to fix this, but maybe it is. At the very least I'd like to just understand what's going on here if this is the correct way to handle this situation.
The await operator suspends evaluation of the enclosing async method until the asynchronous operation represented by its operand completes. When the asynchronous operation completes, the await operator returns the result of the operation, if any. When the await operator is applied to the operand that represents already completed operation, it returns the result of the operation immediately without suspension of the enclosing method. The await operator doesn't block the thread that evaluates the async method. When the await operator suspends the enclosing async method, the control returns to the caller of the method.
Official Document on this
So if we look at the what the documents say about Async/Await you'll notice that
When the await operator is applied to the operand that represents already completed operation, it returns the result of the operation immediately without suspension of the enclosing method.
More then likely OpenAsync(); Is seen as a operand that's already completed as you might not be awaiting your Returns, So the Operation Runs retrieve's your data but because your not suspending anything in OpenAsync It might assume the operand is already completed on the first instance and just continue then the data is loaded so on your second attempt you have the data to work with, as its already populated on the first try.
So i'd like to see a bit more code actually.
However one thing I will say is that .Wait() is Bad If you have to wait for a result and force that wait the better way to do this is .GetAwaiter().GetResult() I can link you a Seminar that explains in details about this. But in Essence .Wait() Throws exceptions into the void and make them extremly difficult to track(Or at-least far more difficult then you'd want them to be)
"Also note in no way am I anywhere near a Expert in Async/Await so feel free to correct me"
Right now my methods look something like this.
ProductManager class in business
public static async Task<List<ProductItem>> GetAllProducts()
{
var context = GetMyContext();
return await context.Products.select(x =>
new ProductItem{ //create item})
.ToListAsync();
}
ProductService class in service.
public async Task<List<ProductItem>> GetAllProducts()
{
return await ProductManager.GetAllProducts();
}
ProductController in application.
public async Task<ActionResult> Index()
{
var ps = new ProductService();
var productsAsync = ps.GetAllProducts();
// Do other work.
var products = await productsAsync;
return View(products);
}
This application gets high usage,
Is this way of doing it totally wrong ?
Should I be await every method ?
Will this start a new thread every time await is called ?
This application gets high usage, Is this way of doing it totally wrong?
No; it looks good to me.
Should I be await every method?
Yes. Once you put in the first await (in ProductManager), then its callers should be awaited, and their callers awaited, and so on, up to the controller action method. This "growth" of async is entirely natural; it's called "async all the way" in my MSDN article on async best practices.
Will this start a new thread every time await is called?
No. Await is about freeing up threads, not using more threads. I have an async intro on my blog that describes how async and await work.
await simply awaits for something to complete. If you don't need the results of a task in your method, you don't need to await it. GetAllProducts should simply return the results of ToListAsync.
public static Task<List<ProductItem>> GetAllProducts()
{
var context = GetMyContext();
return context.Products
.Select(x => new ProductItem{ //create item})
.ToListAsync();
}
async/await adds a bit of overhead, since the compiler has to generate a state machine that stores the original synchronization context, waits for the awaited task to finish and then restores the original synchronization context.
Adding async/await on a method that doesn't need to process the result of the task simply adds overhead. In fact, there are some Roslyn analyzers that detect and fix this issue
I have a small MVC 5 application that calls a web service, and receives a JSON response. I deserialise the response into my own type and it gets passed on to the view and data is displayed by razor.
The controller handler:
public async Task<ActionResult> Search(string q)
{
var vm = new SearchResultViewModel(await _searchService.GetDataAsync(q));
return View(vm);
}
The search service method:
public async Task<ISearchResult> GetDataAsync(string q)
{
var fullRequest = new UriBuilder(RequestUri) {Query = "q=" + q};
var result = await _client.GetAsync(fullRequest.ToString()).ConfigureAwait(false);
if (result.IsSuccessStatusCode)
{
var jsonResponse = await result.Content.ReadAsStringAsync().ConfigureAwait(false);
// How should I call this?
return JsonConvert.DeserializeObject<SearchResult>(jsonResponse);
}
return new SearchResult
}
My question: How should I call JsonConvert.DeserializeObject? It's an inherently CPU bound operation, so is it ok to call synchronously (and block the thread) since I can't return until it's done anyway? If there's a problem with deserialisation, a cancellation token couldn't be used.
If I should call asynchronously, should I use Task.Factory.StartNew() as suggested by intellisense, as a replacement for the deprecated JsonConvert.DeserializeObjectAsync()? This Channel 9 video suggests (at 58mins) that this isn't such a good idea. Perhaps another option, such as Task.Run()? Possibly a bad idea since it might cause SyncContext issues?
Any pointers gratefully received!
Your code is good as is. DeserializeObject will run inside a thread-pool thread since you are using ConfigureAwait(false).
Your overall method (GetDataAsync) would still be asynchronous since it will return to the caller on the first await.
I have a webservice that loads up some plugins (dlls) and calls their Process method. One of the plugins takes a list of members and ensures that they are all included in a MailChimp list.
Here is the code that adds the users to the MailChimp group.
private async Task AddMCUsers(List<Member> _memberList)
{
using (var http = new HttpClient())
{
var creds = Convert.ToBase64String(Encoding.ASCII.GetBytes("user:password");
http.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Basic", creds);
string memberURI = string.Format(#"{0}lists/{1}/members", _baseURI, _memberGroupId);
var jss = new JavaScriptSerializer();
foreach (var user in _memberlist)
{
var _addStatus = "";
try
{
var content = jss.Serialize(new MCPost()
{
email_address = user.Email,
status = "subscribed",
merge_fields = new MCMergeFields()
{
FNAME = user.Firstname,
LNAME = user.Lastname
}
});
using(var result = await http.PostAsync(memberURI, new StringContent(content,Encoding.UTF8, "application/json")))
{
var resultText = await result.Content.ReadAsStringAsync();
if(result.IsSuccessStatusCode)
{
_addStatus = "Success";
var _returnedUser = jss.Deserialize<MCMember>(resultText);
//Store new user's id
user.ServiceId = _returnedUser.id;
}
else
{
_addStatus = "Fail";
}
}
}
catch {
_addStatus = "Error";
}
LogEvent("Add User - " + _addStatus, string.Format("Id: {0} - {1} {2} (Account: {3}) : {4}", user.Id, user.Firstname, user.Lastname, user.AccountId, user.Email));
}
}
}
In normal procedural code, this wouldn't be a problem. However, the only Post method available on the httpClient was PostAsync. Being fairly new to the async/await stuff, I'm not sure the ramifications on the rest of my code ... particularly as it relates to my attempt to reuse the httpClient instead of instantiating a new one for each http call.
I'm not sure what happens with await when its wrapped in a foreach like I have. Will I run into issues with reusing the httpClient to make repeated calls when running asynchronously?
My other question is, what is actually going to be returned. IOW, my understanding is that await returns a Task. However, here, I'm looping through the list and making multiple calls to await PostAsync. My method returns a Task. But which task gets returned? If my calling method needs to wait for completion before moving on, what does its call look like?
private void Process()
{
//Get List
var task = AddMCUsers(list);
task.Wait();
//Subsequent processing
}
I've read that you should use Async all the way. Does this mean my calling method should look more like this?
public async Task Process()
{
//Get list
...
await AddMCUsers(list);
//Other processing
}
Thanks to whatever help you can offer on this.
In normal procedural code, this wouldn't be a problem.
The whole point of async/await is to write asynchronous code in a way that looks practically identical to "normal" synchronous code.
Being fairly new to the async/await stuff, I'm not sure the ramifications on the rest of my code ... particularly as it relates to my attempt to reuse the httpClient instead of instantiating a new one for each http call.
HttpClient was intended to be reused; in fact, it can be used for any number of calls simultaneously.
I'm not sure what happens with await when its wrapped in a foreach like I have.
One way to think of it is that await "pauses" the method until its operation completes. When the operation completes, then the method continues executing. I have an async intro that goes into more detail.
Will I run into issues with reusing the httpClient to make repeated calls when running asynchronously?
No, that's fine.
IOW, my understanding is that await returns a Task.
await takes a Task. It "unwraps" that task and returns the result of the task (if any). If the task completed with an exception, then await raises that exception.
My method returns a Task. But which task gets returned?
The Task returned from an async method is created by the async state machine. You don't have to worry about it. See my intro for more details.
If my calling method needs to wait for completion before moving on, what does its call look like? ... I've read that you should use Async all the way. Does this mean my calling method should look more like this?
Yes, it should look like your second snippet:
public async Task ProcessAsync()
{
//Get list
...
await AddMCUsers(list);
//Other processing
}
The only thing I changed was the Async suffix, which is recommended by the Task-based Asynchronous Pattern.
in your code you should be fine with reusing the HttpClient. What async / await is allow the code to release the execution thread to prevent locking a cpu thread while waiting for the web response. It also releases control back to the caller. When releasing code back to the caller it means that if your Process function does not await your AddMCUsers, Process could finish before AddMCUsers (useful in fire and forget situations to not await a method).
What async/await do not do is affect the logical flow of an individual method. When you await an async web call the execution is paused and then resumed at the same point once the web call returns. There is also thread context tracking and the code resumes in the same context (ie. UI thread or background thread depending on the parent) by default, but this can be changed if needed.
At some point in your code you may want to have a method that blocks until your async code competes and that is where you will want your Task.Wait() call to block execution. If all you use is awaits then it is possible for your program to end before your task competes. See the code example below.
class Program
{
static void Main(string[] args)
{
Task waitForMe = Task.Run(() => waitAsync());
}
static async Task waitAsync()
{
await Task.Delay(5000);
}
}
in the sample with out a Task.Wait call to block the Main method the program will end before the 5 second wait is complete. Having a main method of the following will cause the program to wait for 5 seconds before exiting:
static void Main(string[] args)
{
Task waitForMe = Task.Run(() => waitAsync());
waitForMe.Wait();
}