Could someone tell me a good pattern to use when coding asynchronous http handlers in F#?
I have to implement IHttpAsyncHandler and that interface requires a BeginProcessRequest and EndProcessRequest.
Do I return Async.StartTask? How do I handle state:obj and AsyncCallback?
Off the top of my head: implement handler using async workflow and then expose it with Async.AsBeginEnd
open System
open System.Web
type HttpAsyncHandler() =
let processRequestAsync (context : HttpContext) = async {
// TODO: implement
return()
}
let beginAction, endAction, _ = Async.AsBeginEnd(processRequestAsync)
interface IHttpAsyncHandler with
member this.BeginProcessRequest(context, callback, extraData) = beginAction(context, callback, extraData)
member this.EndProcessRequest(iar) = endAction (iar)
// other members omitted
What are you trying to do, exactly? If you are able, you might want to consider the HttpMessageHandler and its ilk from System.Net.Http. You only have to override the
protected abstract Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request,
CancellationToken cancellationToken);
method, which is easy with an async { ... } |> Async.StartAsTask. You also get better access to the various attributes of HTTP through static typing. Various subclasses allow you to run either through ASP.NET, WCF (self-host), or even third-part platforms like OWIN.
Related
why does the following code always produce an "An asynchronous module or handler completed while an asynchronous operation was still pending"?
When I use 'Dim OriginalUser As ApplicationUser = db.Users.Where(Function(p) p.Id = id).ToList(0)' it works fine.
Lazy Loading is disabled on the ApplicationDBContext which inherits from IdentityDbContext. Why isn't the Context available anymore for the SaveChanges-Part? What am I missing?
Public Async Sub PatchUser(id As String, <FromBody> ChangedUserAttributes As Delta(Of ApplicationUser))
Using ctx As New ApplicationDbContext
Validate(ChangedUserAttributes.GetEntity())
If Not ModelState.IsValid Then
Throw New HttpResponseException(New HttpResponseMessage(HttpStatusCode.BadRequest))
End If
Dim OriginalUser As ApplicationUser = Await ctx.Users.SingleOrDefaultAsync(Function(p) p.Id = id)
If OriginalUser Is Nothing Then
Throw New HttpResponseException(HttpStatusCode.NotFound)
End If
Try
ChangedUserAttributes.TrySetPropertyValue("Email", "Emil")
ChangedUserAttributes.Patch(OriginalUser)
Await ctx.SaveChangesAsync
Return
Catch ex As Exception
Throw New HttpResponseException(New HttpResponseMessage(HttpStatusCode.BadRequest))
End Try
End Using
End Sub
It's because of Async Sub. This method should be an asynchronous function returning Task, and (if you call it yourself) it would need to be called with Await.
You may find my article on async on ASP.NET helpful:
When an asynchronous handler completes the request, but ASP.NET detects asynchronous work that hasn’t completed, you get an InvalidOperationException with the message, “An asynchronous module or handler completed while an asynchronous operation was still pending.” This is usually due to asynchronous code calling an async void method
As well as my article on async best practices:
Avoid async void... Async methods returning void don’t provide an easy way to notify the calling code that they’ve completed. It’s easy to start several async void methods, but it’s not easy to determine when they’ve finished.
I need to query against a Web API that sends responses which can be encrypted and/or compressed and/or Base64 encoded and I'd like to implement this as a chain of HttpMessageHandlers very much like outlined in this post, which is for Web API though.
There is a constructor for HttpClient taking an HttpMessageHandler, so that is a start. Do I have to come up with a solution for chaining multiple handlers myself or is there maybe a better option?
The easiest way to chain HttpMessageHandlers is to inherit from DelegatingHandler, which takes an inner HttpMessageHandler in its constructor, which it calls in its base SendAsync implementation.
public class MyHandler1 : DelegatingHandler
{
protected async override Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request,
CancellationToken cancellationToken)
{
// do something before the inner handler runs (modify the request?)
var response = await base.SendAsync(request, cancellationToken);
// do something after the inner handler runs (modify the repsonse?)
return response;
}
}
Armed with multiple of these, you chain them together in whatever order you want when you construct HttpClient:
var client = new HttpClient(
new MyHandler1(
new MyHandler2(
new MyHandler3(...))));
I'm using a "Post" async method of webApi rest service:
public async Task<object> Post([FromBody]string data)
{
object response = ExecuteServerLogics(data);
return response;
}
This above code worked good but in some of the client's calls, we experienced performance issues.
After reading some articles here, i've noticed that our webApi rest service,
is not really working asynchronously with its incoming web requests,
because we forgot to use async/await pattern :
public async Task<object> Post([FromBody]string data)
{
object response = await Task<object>.Run( () =>
{
return ExecuteServerLogics(data);
});
return response;
}
After this fix we noticed the performance got better,
but we found another critic problem:
when accessing HttpContext.Current - it returns Null reference:
public async Task<object> Post([FromBody]string data)
{
object response = await Task<object>.Run( () =>
{
var currentContext = HttpContext.Current; // Returns Null!
return ExecuteServerLogics(data);
});
return response;
}
We tried to found a solution for it, and in most posts we found that we should pass the
worker thread's HttpContext reference into the inner Task that executes the server logics.
The problem with this solution is that the server's logics methods, use many static classes that use
"HttpContext.Current" such as -
Loggers calls.
static security classes that retrieves the user.identity
static security classes that retrives the incoming request's session data, etc.
Therefore, passing the "HttpContext.Current" reference of the worker thread won't solve it.
When we tried the next solution:
public async Task<object> Post([FromBody]string data)
{
// Save worker context:
var currentContext = HttpContext.Current;
object response = await Task<object>.Run( () =>
{
// Set the context of the current task :
HttpContext.Current = currentContext ; // Causes the calls not to work asynchronously for some reason!
// Executes logics for current request:
return ExecuteServerLogics(data);
});
return response;
}
for some reason, we noticed the performance got worse again, like it had returned working synchronously again.
Our problems are:
1. Why in the last example, setting the "HttpContext.Current" inside the await task,
causes the requests to return the same bad performance results which similar to the synchronous results?
2. Is there another way we can use "HttpContext.Current" inside the inner task that call - "ExecuteServerLogics",
and in all the static classes which also call "HttpContext.Current"?
am I doing the entire design wrong somehow?
Thanks!
From the beginning:
public async Task<object> Post([FromBody]string data)
{
object response = ExecuteServerLogics(data);
return response;
}
Don't ignore compiler warnings; the compiler will generate a warning for this method that specifically states it will run synchronously.
Moving on:
in some of the client's calls, we experienced performance issues.
Asynchronous code on the server will not be faster for a single call in isolation. It only helps you scale your server.
In particular, Task.Run will negate all the performance benefits of async and then degrade performance a bit beyond that. I believe the improvement in performance that you measured was coincidental.
in most posts we found that we should pass the worker thread's HttpContext reference into the inner Task that executes the server logics.
Those posts are wrong. IMHO. You end up using the HttpContext object from a background thread, when that object is specifically designed to be only accessed from a request thread.
am I doing the entire design wrong somehow?
I do recommend you take a step back and think about the big picture. When a request comes in, it has a certain amount of work to do. Whether that work is done synchronously or asynchronously is immaterial to the client; both approaches will take about the same amount of time.
If you need to return early to the client, then you'll need a completely different architecture. The usual approach is to queue the work to a reliable queue (e.g., Azure queue), have a separate backend (e.g., Azure WebRole), and proactively notify the client when the work is completed (e.g., SignalR).
That's not to say that async is useless, though. If ExecuteServerLogics is an I/O bound method, then it should be made asynchronous rather than blocking, and then you can use asynchronous methods as such:
public async Task<object> Post([FromBody]string data)
{
object response = await ExecuteServerLogicsAsync(data);
return response;
}
This will enable your server to be more responsive and scalable overall (i.e., not get overwhelmed by many requests).
If your task is inside your ApiController-derived class, you can use:
var ctx = this.Request.Properties["MS_HttpContext"] as System.Web.HttpContextWrapper;
This will give you an HttpContext wrapper with all the usual properties.
Amir I think you're looking for something like this below. I've been dealing with the same issue, trying to optimize a series of calls. It needs to be async all the way through, which means your ExecuteServerLogics() would need to be async, and you'd have to mark the containing lamda as async as well.
I believe following that pattern you can probably eliminate most of your performance issues. Nice passing the context through like that.
public async Task<object> Post([FromBody]string data)
{
// Save worker context:
var currentContext = HttpContext.Current;
object response = await Task<object>.Run(async () =>
{
// Set the context of the current task :
HttpContext.Current = currentContext ;
// Executes logics for current request:
return await ExecuteServerLogics(data);
});
return response;
}
Using Asp.net WebApi (RC), how can I catch errors that are not caught by Exception Filters or Application_Error() in global.asax?
With both of these in place it seems that there is a class of exceptions still not covered. For example: ApiControllerActionSelector_AmbiguousMatch error (Multiple actions were found that match the request: {0}).
I'm not specifically concerned about the above error, this error just pointed out that there is a class of errors that aren't being caught by either my Exception Filter or Application_Error method.
So how can I cover all my bases?
You're right, there are several classes of exception not trapped by either Application_Error or ExceptionFilter. The Web API request pipeline is processed separately from the ASP.NET MVC pipeline (at least through MVC 4) so the MVC Application_Error doesn't kick-in. Also, if your application throws HttpResponseException type exceptions, they will not be caught by an ExceptionFilter by design (see the ExceptionFilter paragraph). To access all exceptions thrown by your code, you'll need to create a DelegatingHandler along the lines of this code:
public class ResponseExceptionTrapper : DelegatingHandler
{
protected override Task<HttpResponseMessage> SendAsync(
HttpRequestMessage request,
CancellationToken cancellationToken)
{
return base
.SendAsync(request, cancellationToken)
.ContinueWith(response =>
{
var result = response.Result;
if (!result.IsSuccessStatusCode)
{
var exceptionResult = string.Format(
"Response exception: Path({0}) Status({1}) ",
request.RequestUri,
result.StatusCode);
if (result.Content != null)
{
var exceptionReadTask =
result.Content.ReadAsStringAsync();
exceptionReadTask.Wait();
exceptionResult += "Message:\n\r" +
exceptionReadTask.Result;
}
// Do something appropriate with exceptionResult
}
return result;
}, cancellationToken);
}
}
You can wire up the handler with this line in your global config logic:
GlobalConfiguration.Configuration.MessageHandlers.Add(
new ResponseExceptionTrapper());
I believe that Exception Filters only get called once the action is invoked (in which case there is a try/catch around it). The Ambiguous match error would pop up before that in the pipeline and there could be other errors that pop up after that (e.g. a formatter error) as you mention.
I'm not sure you can have one solution to address all of the aspects (since the hosting implementation can vary), but you could try overriding the HttpControllerDispatcher. This class is one of the "root" classes used in the pipeline. Specifically, you could override SendAsync to do your try/catch and handle accordingly.
I have a ASHX that do bulk insert at a SQLite. This page load for 2sec +/-
Its a good practice implement it with Async Http Handler to not hold a ASP.NET Thread while I do I/O work.
To turn my IHttpHandler into IHttpAsyncHandler I just did this, its correct?
-Changed interface that I implement at ASHX to IHttpAsyncHandler
-Add this variable and constructor:
readonly Action<HttpContext> process;
public ClassConstructor()
{
process = ProcessRequest;
}
-Implemented 2 IHttpAsyncHandler methods:
public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData)
{
return process.BeginInvoke(context, cb, extraData);
}
public void EndProcessRequest(IAsyncResult result)
{
process.EndInvoke(result);
}
My main doubt is if I should mantain the original ProcessRequest and just call it with a Action as I did.
And if it´s ok to use context.Response inside ProcessRequest, or this work should be done at EndProcessRequest