Hi I run across this sort of oddity regulaly I've just started a project to support an existing system, I recently came across a DB call that was wrapped in an async await call, I found that it was throwing exceptions 2 /3 of the time.
I removed the async await, and the pallalel foreach to populate the objects, and all was working correctly and running 2 seconds faster, the website already calls the service async with ajax. I'm against using async calls inside server code when accessing outside resources. If the process is too long then it needs refactoring to simplify the call. .02c Davy *Si hoc legere scis nimium eruditionis habes*. On Tue, Jun 21, 2016 at 4:42 AM, Greg Keogh <gfke...@gmail.com> wrote: > Are the calls on the same server? If so remove the async await, from the >> call and try again, did you get an error? >> > > Yesterday I gave up and used a synchronous WebClient.DownloadString inside > the WebApi controller and it worked fine. > > Today as an experiment I rejigged the code a bit. I made the controller > method async Task<IHttpActionResult> and inside it I created two Task using > await WebRequest Task.Factory.FromAsync(beginxx,endxx). I did a WhenAll on > the two tasks and they all worked fine. > > One call was to localhost where I was debugging and the other to a remote > server. So today this has disproved my theory (like you had) that debugging > and calling localhost was a problem. Today it all just works! > > It opens up philosophical questions about where in the WebApi call stack > should the asynchrony start and stop. Web searches find lots of often > contradictory arguments and advice on this matter. > > *GK* >
