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
Related
I want to be able to load a user from a cloud database on each request and have that available on the request in a controller using asp.net mvc. The problem is the current framework does not support doing async operations from action filters. So OnActionExecuting, OnAuthorization methods do not allow me to do this.. for example I have the following code which DOES NOT work (so don't try it).. You get an exception : "An asynchronous module or handler completed while an asynchronous operation was still pending."
protected async override void OnAuthorization(AuthorizationContext filterContext)
{
var user = filterContext.HttpContext.User;
if (!user.Identity.IsAuthenticated)
{
HandleUnauthorizedRequest(filterContext);
return;
}
using (var session = MvcApplication.DocumentStore.OpenAsyncSession())
{
User currentUser = await session.LoadAsync<User>(user.Identity.Name);
if (currentUser == null)
{
HandleUnauthorizedRequest(filterContext);
return;
}
filterContext.HttpContext.Items["User"] = currentUser;
}
}
So is there any other way of being able to do this? I notice there is a begin execute method in the base Controller:
protected override IAsyncResult BeginExecute(RequestContext requestContext, AsyncCallback callback, object state)
{
return base.BeginExecute(requestContext, callback, state);
}
Could I do it there possibly?
The question is three months old so I guess you've managed to work around this. Anyway, I'll add my solution here, as I had to do something similar.
I used the ToAsync method from the ParallelExtensionsExtras library. This is my class:
public class AsyncControllerBase : Controller
{
protected override IAsyncResult BeginExecute(System.Web.Routing.RequestContext requestContext, AsyncCallback callback, object state)
{
return ExecuteCoreAsync(requestContext, state).ToAsync(callback, state);
}
protected override void EndExecute(IAsyncResult asyncResult)
{
IAsyncResult baseAsyncResult = ((Task<IAsyncResult>)asyncResult).Result;
base.EndExecute(baseAsyncResult);
}
protected virtual async Task<IAsyncResult> ExecuteCoreAsync(System.Web.Routing.RequestContext requestContext, object state)
{
await DoStuffHereOrInDerivedClassAsync();
var baseBeginExecuteCompletion = new TaskCompletionSource<IAsyncResult>();
AsyncCallback callback = ar =>
{
baseBeginExecuteCompletion.SetResult(ar);
};
// OnActionExecuting will be called at this point
var baseAsyncResult = base.BeginExecute(requestContext, callback, state);
await baseBeginExecuteCompletion.Task;
return baseAsyncResult;
}
protected override void OnActionExecuting(ActionExecutingContext filterContext)
{
base.OnActionExecuting(filterContext);
}
}
See also this documentation from Microsoft on converting between Task and IAsyncResult.
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.
I'm just getting started with ServiceStack and, as a test case, I am looking to rework an existing service which is built using standard ASP.Net handlers. I've managed to get it all working as I want it but have certain aspects which make use of the ASP.Net Session object.
I've tried adding IRequiresSessionState into the service interface:
public class SessionTestService : RestServiceBase<SessionTest>, IRequiresSessionState {
public override object OnPost(SessionTest request) {
// Here I want to use System.Web.HttpContext.Current.Session
}
}
The trouble is I can't seem to get it to work as the Session object is always null.
I've done a lot of Googling and have puzzled over https://github.com/mythz/ServiceStack/blob/master/tests/ServiceStack.WebHost.IntegrationTests/Services/Secure.cs and similar but I can't find any example code which does this (which surprises me). Can anyone explain why the above doesn't work and advise what I need to do to get it working?
Note: Ultimately I'll probably look to replace this with Redis or will try to remove any serverside session requirement, but I figured that I'd use the ASP.Net implementation for the time being, to get things working and to avoid reworking it more than is necessary at this point.
Using ServiceStack ISession
ServiceStack has a new ISession interface backed by ICacheClient that lets you share same ISession between MVC Controllers, ASP.NET base pages and ServiceStack's Web Services which share the same Cookie Id allowing you to freely share data between these web frameworks.
Note: ISession is a clean implementation that completely by-passes the existing ASP.NET session with ServiceStack's own components as described in ServiceStack's MVC PowerPack and explained in detail in the Sessions wiki page.
To easily make use of ServiceStack's Session (Cache & JSON Serializer) have your Controllers inherit from ServiceStackController (in MVC) or PageBase (in ASP.NET)
There is also new Authentication / Validation functionality added in ServiceStack which you can read about on the wiki:
Authentication and authorization
Validation
Using ASP.NET Session
Essentially ServiceStack is just a set of lightweight IHttpHandler's running on either an ASP.NET or HttpListener host. If hosted in IIS/ASP.NET (most common) it works like a normal ASP.NET request.
Nothing in ServiceStack accesses or affects the configured Caching and Session providers in the underlying ASP.NET application. If you want to enable it you would need to configure it as per normal in ASP.NET (i.e. outside of ServiceStack) see:
http://msdn.microsoft.com/en-us/library/ms178581.aspx
Once configured you can access the ASP.NET session inside a ServiceStack web service via the singleton:
HttpContext.Current.Session
Or alternatively via the underlying ASP.NET HttpRequest with:
var req = (HttpRequest)base.RequestContext.Get<IHttpRequest>().OriginalRequest;
var session = req.RequestContext.HttpContext.Session;
Although because of the mandatory reliance on XML config and degraded performance by default, I prefer to shun the use of ASP.NET's Session, instead opting to use the cleaner Cache Clients included with ServiceStack.
Basically the way Sessions work (ASP.NET included) is a cookie containing a unique id is added to the Response uniquely identifying the browser session. This id points to a matching Dictionary/Collection on the server which represents the browsers' Session.
The IRequiresSession interface you link to doesn't do anything by default, it simply is a way to signal to either a Custom Request Filter or base web service that this request needs to be authenticated (i.e. two places where you should put validation/authentication logic in ServiceStack).
Here's a Basic Auth implementation that looks to see if a web service is Secure and if so make sure they have authenticated.
Here's another authentication implementation that instead validates all services marked with an [Authenticate] attribute, and how to enable Authentication for your service by adding the Attribute on your Request DTO.
New Authentication Model in ServiceStack
The above implementation is apart of the multi-auth provider model included in the next version of ServiceStack. Here's the reference example showing how to register and configure the new Auth model in your application.
Authentication Strategies
The new Auth model is entirely an opt-in convenience as you can simply not use it and implement similar behaviour yourself using Request Filters or in base classes (by overriding OnBeforeExecute). In fact the new Auth services are not actually built-into ServiceStack per-se. The entire implementation lives in the optional ServiceStack.ServiceInterfaces project and implemented using Custom Request Filters.
Here are different Authentication strategies I've used over the years:
Mark services that need authentication with an [Attribute]. Likely the most idiomatic C# way, ideal when the session-id is passed via a Cookie.
Especially outside of a Web Context, sometimes using a more explicit IRequiresAuthentication interface is better as it provides strong-typed access to the User and SessionId required for Authentication.
You can just have a 1-liner to authenticate on each service that needs it - on an adhoc basis. A suitable approach when you have very few services requiring authentication.
That's a great and comprehensive answer by #mythz. However, when trying to access the ASP.NET session by HttpContext.Current.Session within a ServiceStack web service, it always returns null for me. That's because none of the HttpHandlers within ServiceStack are adorned with the IRequiresSessionState interface, so the .NET Framework does not provide us with the session object.
To get around this, I've implemented two new classes, both of which use the decorator pattern to provide us with what we need.
Firstly, a new IHttpHandler which requires session state. It wraps the IHttpHandler provided by ServiceStack and passes calls through to it...
public class SessionHandlerDecorator : IHttpHandler, IRequiresSessionState {
private IHttpHandler Handler { get; set; }
internal SessionHandlerDecorator(IHttpHandler handler) {
this.Handler = handler;
}
public bool IsReusable {
get { return Handler.IsReusable; }
}
public void ProcessRequest(HttpContext context) {
Handler.ProcessRequest(context);
}
}
Next, a new IHttpHandlerFactory which delegates the responsibility for generating the IHttpHandler to ServiceStack, before wrapping the returned handler in our new SessionHandlerDecorator...
public class SessionHttpHandlerFactory : IHttpHandlerFactory {
private readonly static ServiceStackHttpHandlerFactory factory = new ServiceStackHttpHandlerFactory();
public IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated) {
var handler = factory.GetHandler(context, requestType, url, pathTranslated);
return handler == null ? null : new SessionHandlerDecorator(handler);
}
public void ReleaseHandler(IHttpHandler handler) {
factory.ReleaseHandler(handler);
}
}
Then, it's just a matter of changing the type attributes in the handlers in Web.config to SessionHttpHandlerFactory instead of ServiceStack.WebHost.Endpoints.ServiceStackHttpHandlerFactory, ServiceStack, and your web services should now have the ASP.NET session avaialble to them.
Despite the above, I fully endorse the new ISession implementation provided by ServiceStack. However, in some cases, on a mature product, it just seems too big a job to replace all uses of the ASP.NET session with the new implementation, hence this workaround!
Thanks #Richard for your answer above. I am running a new version of service stack and they have removed the ServiceStackHttpFactory with HttpFactory. Instead of having
private readonly static ServiceStackHttpHandlerFactory factory = new ServiceStackHttpHandlerFactory();
You need to have
private static readonly HttpHandlerFactory Factory = new HttpHandlerFactory();
Here is updated code for this service
using ServiceStack;
using System.Web;
using System.Web.SessionState;
namespace MaryKay.eCommerce.Mappers.AMR.Host
{
public class SessionHttpHandlerFactory : IHttpHandlerFactory
{
private static readonly HttpHandlerFactory Factory = new HttpHandlerFactory();
public IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated)
{
var handler = Factory.GetHandler(context, requestType, url, pathTranslated);
return handler == null ? null : new SessionHandlerDecorator(handler);
}
public void ReleaseHandler(IHttpHandler handler)
{
Factory.ReleaseHandler(handler);
}
}
public class SessionHandlerDecorator : IHttpHandler, IRequiresSessionState
{
private IHttpHandler Handler { get; set; }
internal SessionHandlerDecorator(IHttpHandler handler)
{
Handler = handler;
}
public bool IsReusable
{
get { return Handler.IsReusable; }
}
public void ProcessRequest(HttpContext context)
{
Handler.ProcessRequest(context);
}
}
}
As of ServiceStack 4.5+ the HttpHandler can also support Async. Like so:
namespace FboOne.Services.Host
{
public class SessionHttpHandlerFactory : IHttpHandlerFactory
{
private static readonly HttpHandlerFactory Factory = new HttpHandlerFactory();
public IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated)
{
var handler = Factory.GetHandler(context, requestType, url, pathTranslated);
return handler == null ? null : new SessionHandlerDecorator((IHttpAsyncHandler)handler);
}
public void ReleaseHandler(IHttpHandler handler)
{
Factory.ReleaseHandler(handler);
}
}
public class SessionHandlerDecorator : IHttpAsyncHandler, IRequiresSessionState
{
private IHttpAsyncHandler Handler { get; set; }
internal SessionHandlerDecorator(IHttpAsyncHandler handler)
{
Handler = handler;
}
public bool IsReusable
{
get { return Handler.IsReusable; }
}
public void ProcessRequest(HttpContext context)
{
Handler.ProcessRequest(context);
}
public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData)
{
return Handler.BeginProcessRequest(context, cb, extraData);
}
public void EndProcessRequest(IAsyncResult result)
{
Handler.EndProcessRequest(result);
}
}
}
I have an item that I store in the HttpContext:
HttpContext.Current.Items["myItem"] = "123";
I can access this no problem from any of a page's methods. For example:
protected override void OnLoad(EventArgs e)
{
string l_myItemVal = HttpContext.Current.Items["myItem"] as string; // "123"
}
This works fine.
However, when calling one of the page's web methods via AJAX, this fails:
[System.Web.Services.WebMethod]
[System.Web.Script.Services.ScriptMethod]
public static string MyWebMethod()
{
string l_myItemVal = HttpContext.Current.Items["myItem"] as string; // NULL
}
Is the HttpContext of an asynchronous call different from the HttpContext for the page?
HttpContext.Items only holds items during a single request. Your AJAX request is a second request, and has it's own Items property.
Maybe you need to enable session state to make this work:
[System.Web.Services.WebMethod(true)]
In this question & answer, I found one way to make ASP.NET MVC support asynchronous processing. However, I cannot make it work.
Basically, the idea is to create a new implementation of IRouteHandler which has only one method GetHttpHandler. The GetHttpHandler method should return an IHttpAsyncHandler implementation instead of just IHttpHandler, because IHttpAsyncHandler has Begin/EndXXXX pattern API.
public class AsyncMvcRouteHandler : IRouteHandler
{
public IHttpHandler GetHttpHandler(RequestContext requestContext)
{
return new AsyncMvcHandler(requestContext);
}
class AsyncMvcHandler : IHttpAsyncHandler, IRequiresSessionState
{
public AsyncMvcHandler(RequestContext context)
{
}
// IHttpHandler members
public bool IsReusable { get { return false; } }
public void ProcessRequest(HttpContext httpContext) { throw new NotImplementedException(); }
// IHttpAsyncHandler members
public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData)
{
throw new NotImplementedException();
}
public void EndProcessRequest(IAsyncResult result)
{
throw new NotImplementedException();
}
}
}
Then, in the RegisterRoutes method of file Global.asax.cs, register this class AsyncMvcRouteHandler.
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.Add(new Route("{controller}/{action}/{id}", new AsyncMvcRouteHandler())
{
Defaults = new RouteValueDictionary(new { controller = "Home", action = "Index", id = "" }),
});
}
I set breakpoint at ProcessRequest, BeginProcessRequest and EndProcessRequest. Only ProcessRequest is executed. In another word, even though AsyncMvcHandler implements IHttpAsyncHandler. ASP.NET MVC doesn't know that and just handle it as an IHttpHandler implementation.
How to make ASP.NET MVC treat AsyncMvcHandler as IHttpAsyncHandler so we can have asynchronous page processing?
I had the same issue, however I found that it was because my catch all route handler:
routes.MapRoute(
"Default",
"{controller}/{action}",
new { controller = "Home", action = "Index" }
);
Was picking up the request, not the custom route I added that dealt with the async route handler. Perhaps by using the .mvc in your custom route defintion you created a distinction so that it was used rather than the synchronous catch-all.
After hours of hassle with the code, I found out the issue.
In my Visual Studio 2008, when I press Ctrl+F5, the Application Development Server is launched and IE is popped up to access "http://localhost:3573/". In this case, the sync API ProcessRequest is invoked. The stack trace is like this.
MyMvcApplication.DLL!MyMvcApplication.AsyncMvcRouteHandler.AsyncMvcHandler.ProcessRequest(System.Web.HttpContext
httpContext =
{System.Web.HttpContext}) Line 59 C#
System.Web.Mvc.dll!System.Web.Mvc.MvcHttpHandler.VerifyAndProcessRequest(System.Web.IHttpHandler
httpHandler,
System.Web.HttpContextBase
httpContext) + 0x19 bytes
System.Web.Routing.dll!System.Web.Routing.UrlRoutingHandler.ProcessRequest(System.Web.HttpContextBase
httpContext) + 0x66 bytes
System.Web.Routing.dll!System.Web.Routing.UrlRoutingHandler.ProcessRequest(System.Web.HttpContext
httpContext) + 0x28 bytes
System.Web.Routing.dll!System.Web.Routing.UrlRoutingHandler.System.Web.IHttpHandler.ProcessRequest(System.Web.HttpContext
context) + 0x8 bytes
MyMvcApplication.DLL!MyMvcApplication._Default.Page_Load(object
sender = {ASP.default_aspx},
System.EventArgs e =
{System.EventArgs}) Line 13 + 0x1a
bytes C#
However, when I change the URL in IE to be "http://localhost:3573/whatever.mvc", it hits the BeginProcessRequest. The stack trace is like this.
MyMvcApplication.DLL!MyMvcApplication.AsyncMvcRouteHandler.AsyncMvcHandler.BeginProcessRequest(System.Web.HttpContext
context = {System.Web.HttpContext},
System.AsyncCallback cb = {Method =
{Void
OnAsyncHandlerCompletion(System.IAsyncResult)}},
object extraData = null) Line 66 C#
System.Web.dll!System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
+ 0x249 bytes System.Web.dll!System.Web.HttpApplication.ExecuteStep(System.Web.HttpApplication.IExecutionStep
step =
{System.Web.HttpApplication.CallHandlerExecutionStep},
ref bool completedSynchronously =
true) + 0x9c bytes
System.Web.dll!System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(System.Exception
error) + 0x133 bytes
System.Web.dll!System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(System.Web.HttpContext
context, System.AsyncCallback cb,
object extraData) + 0x7c bytes
System.Web.dll!System.Web.HttpRuntime.ProcessRequestInternal(System.Web.HttpWorkerRequest
wr =
{Microsoft.VisualStudio.WebHost.Request})
+ 0x17c bytes System.Web.dll!System.Web.HttpRuntime.ProcessRequestNoDemand(System.Web.HttpWorkerRequest
wr) + 0x63 bytes
System.Web.dll!System.Web.HttpRuntime.ProcessRequest(System.Web.HttpWorkerRequest
wr) + 0x47 bytes
WebDev.WebHost.dll!Microsoft.VisualStudio.WebHost.Request.Process()
+ 0xf1 bytes WebDev.WebHost.dll!Microsoft.VisualStudio.WebHost.Host.ProcessRequest(Microsoft.VisualStudio.WebHost.Connection
conn) + 0x4e bytes
It seems that only url with ".mvc" suffix can make asynchronous API invoked.
I have tried to do this in the past, I manage to either get the view to render and then all the async tasks would finish. Or the async tasks to finish but the view would not render.
I created a RouteCollectionExtensions based on the original MVC code. In my AsyncMvcHandler, I had an empty method (no exception) for ProcessMethod.