... will the Application_Start method be ran again for the next request(s) or not?
Does it depend on ASP.NET version, hosting server version and/or other context?
I am trying to determine if it's a good thing to load critical assemblies there or not. For example data access assemblies which are vital to the functioning of the whole application or not. Failure to load such assembly would make subsequent requests useless.
Application_Start will be fired only once for each web application so in your case, the start will not happen again for subsequent requests.
Typically, I prefer to put one time start-up code in the application start within try-catch and if there is an exception then set the global error flag. In each BeginRequest, the flag is checked and if it is set, user is redirected to a custom error page indicating the site is down and please contact the administrator.
Related
I created a service with a RESTful API in ASP.NET, hosted in IIS. Inside this service, I would like to create an actor system with Akka.NET.
Upon creating the actor system:
var actorSystem = ActorSystem.Create("myActorSystem");
The following exception is thrown:
A first chance exception of type 'System.InvalidOperationException' occurred in System.Web.dll
Additional information: An asynchronous operation cannot be started at this time. Asynchronous operations may only be started within an asynchronous handler or module or during certain events in the Page lifecycle. If this exception occurred while executing a Page, ensure that the Page is marked <%# Page Async="true" %>. This exception may also indicate an attempt to call an "async void" method, which is generally unsupported within ASP.NET request processing. Instead, the asynchronous method should return a Task, and the caller should await it.
The actor system is inherently a concurrent system with asynchronous messages being exchanged between actors. As explained here, this actor system would not survive IIS taking down the AppDomain, which is probably why the aforementioned exception is thrown.
This article explains how to run background tasks in ASP.NET. However, I don't see how I could use this for my actor system, as I have no control over the lifecycle of background tasks that might be created by Akka.NET.
Is there a way to make this work, or should I abandon the idea of having an actor system in an ASP.NET application?
EDIT: I also saw a question on Stackoverflow about implementing a REST service using Akka. Any advice about a solution similar to the Spray toolkit, but working for Akka.NET would be welcome.
I've used Akka.NET and Akka.Remote inside ASP.NET MVC applications that are doing up to 1000 requests per second on EC2 - so I'll share some of the tips and tricks I used to get it up and running successfully. Had a prototype version that even used Akka.Cluster but ended up not shipping that version.
Best place to call ActorSystem.Create is inside Global.asax Application_Start().
Hang onto a static reference to the ActorSystem object inside Global.asax itself, using a static field or property. Helps ensure that the ActorSystem itself doesn't get garbage-collected in long-running applications.
Create a separate static helper class to initialize any top-level actors your applications needs - i.e. actors at the top of the /user/ hierarchy. This class should also provide actor paths that your ASP.MVC controllers and action methods can use for Tell and Ask operations.
Creating the ActorSystem is a bit of an expensive operation, because lots of system-level stuff gets fired up at once. It's definitely best to do this once at application startup and then just cache the result inside the Application class.
Creating individual actor instances is cheap - you should be able to do this no-problem inside ASP.NET MVC action methods. If you see this error come up again, please let us know what part in the request-handling process this error occurred and with which version of ASP.NET.
Edit: added some updated guidance for how to do this on ASP.NET Core
https://petabridge.com/blog/akkadotnet-aspnetcore/
Keep your ActorSystem as a shared property in some static class container - this way you may access it from the rest of your application. Actor system initialization/disposal can be done by:
Global.asax - use ActorSystem.Create(...) inside Global.asax Application_Start and dispose it with system.Shutdown() on Application_End.
OWIN - create actor system in OWIN's Startup.Configuration method and shut it down by binding to host.OnAppDisposing event (how-to link).
Remember that IIS will startup your web app only after first request and tear it down automatically after some time when it's idle. Therefore make sure, that your deployment script will ping application after publishing and set idle timeout (link) for long enough if you want your Akka actor system to run continuously.
Second option
Separate your Actor System logic and deploy it, for example, as a Windows Service (or Linux deamon). Turn on Akka.Remoting for it and create a proxy client, which will forward all application long-running sensitive tasks to external service. Similar solution is often used for things such as schedulers or event buses, when your application logic must be working continuously.
I have an MVC+SignalR application that has a lot of Reactive Extensions subscriptions flying around, all of which are projections of data coming from a Socket in realtime. Some of these subscriptions are not working as expected, and when they raise an exception it just goes into the void unless I'm debugging.
I had hoped that I could use Elmah to automatically log these unhandled exceptions, but it seems that unless the exception occurs on the same thread that's processing the request/response, eg it causes a yellow screen of death, Elmah isn't touching it. So my question is twofold:
Can I get Elmah to automatically log exceptions on background/worker processes?
If the answer to #1 is "no", what's my next best option, other than wrapping my subscriptions in try/catch blocks at a very high level?
Ad 1) If it doesn't happen already it probably doesn't.
I don't know how exactly you use background threads, but I will try to explain were ELMAH handling is working. ELMAH is integrated into ASP.NET pipeline, and when the error occurs it is handled by ASP.NET pipeline, which shows error page (like http error 500) and invoke ErrorLogModule. Moreover quoting Using HTTP Modules and Handlers to Create Pluggable ASP.NET Components -> Adding ELMAH to an ASP.NET Web Application
The section adds the ErrorLogModule HTTP module to the
ASP.NET HTTP pipeline. Make sure you include this
setting, otherwise ELMAH won't be listening for the Error event, and
therefore won't be logging any unhandled exceptions.
Ad 2) Because you are using Reactive Extensions you can handle onError in which you can automatically log into Elmah. If you don't want to writer everywhere error hangling in OnError, just create your own function or method extension which will wrap it automatically for you. Writing into ELMAH manually is simple just call:
Elmah.ErrorSignal.FromCurrentContext().Raise(ex);
My Azure .Net web app uses a shared cache role which can sometimes throw an exception meaning, "retry later" if it is hot swapping. Currently, that causes my web app to error. However, this is thrown before my app has even started up since it is the framework/IIS which has attempted to setup the cache and failed.
How can I catch these exceptions and do something useful when redirecting to an error page would still require my app and config/cache to load, which would cause the exceptions again? Even if I could catch the exception in Application_Error, I don't think I can retry the connection to the cache because I didn't create it in the first place.
Few questions :
Didn't clearly get your question. So it's your client calling cache, who is getting these errors right?
Are you using session state provider for cache? If not, When you said you are not making connections to the cache, what did you mean?
What is the exact error?
Is it intermittent? Is it always happening during role startup, the case u mentioned here?
I have an ASP.NET-based web app on Azure with a Web API. Yesterday, I started to get exceptions from the app whenever one of the API calls was invoked.
I don't have an exception logger intercepting application exceptions at the moment, however, I do have audit logging on each of the API calls which 99% of the time catches exceptions and reports problems to me.
In this particular case, it appears an exception is occurring further up the stack from the audit logging. There's not much code I have written which is invoked above there to be honest. There is also an IIS error page configured, so exception information is not passed down to the client. I have had a look in the event log and there's nothing in there.
In reaction to the problem, I spun up a new Azure instance, made that live and relegated the problematic instance to staging. The new instance works fine. If I restart the (now) staging instance by reconfiguring web.config to disable IIS errors then that instance will also work fine!
So does anyone know how I can extract unhandled exception information from a running app domain without having to restart it or affect it in any way?
I will be putting exception logging in soon, don't worry :-) But if there is a way to crack this without having to wait for another occurrence of the problem then that would be great!
UPDATE:
I logged onto the server and managed to get the following information from the "detailed response":
HTTP Error 500.0 - Internal Server Error The page cannot be displayed
because an internal server error has occurred. Detailed Error
Information:
Module ManagedPipelineHandler
Notification ExecuteRequestHandler
Handler System.Web.Http.WebHost.HttpControllerHandler
Error Code 0x00000000
Requested URL http:// 10.77.52.122:80/api/Login
Physical Path E:\sitesroot\0\api\Login
Logon Method Anonymous
Logon User Anonymous
Request Tracing Directory
C:\Resources\directory\34c6b40352d4449d8a19274caa328300.Web.UI.DiagnosticStore\FailedReqLogFiles\Web
I then configured Failed Request Tracing - which promptly made the error go away!
Anyone have any ideas? I'm probably going to have to wait for it to happen again, but by then there'll be some more exception logging.
thanks
Kris
I am using NHibernate on a new ASP.NET project, and am running into what I believe to be strange behavior. I am attempting to manage my session by using an HttpModule to catch the EndRequest event and close the session. This is working fine, however, after the EndRequest event fires, I am getting an exception in the OnLoad event of one of my custom controls that is attempting to read a Property from my object that is lazy loaded. I get an exception stating 'failed to lazily initialize a collection, no session or session was closed'. Turning lazy load off for these properties does fix the problem, and is an acceptable solution. But this seems to be going against what I always thought to be true.
I would assume that the OnLoad event and all server side processing would be done at the point that EndRequest is fired. This is also the first time that I have used IIS 7 on a project. Is this a reason for the behavior? What is the expected behavior?
I just had a 'palm slaps forehead' moment. Despite the fact that I am in fact deploying to an IIS 7 server, I have been debugging using the VS 2008 Built in Web server (Casini). Casini passes all requests through the ASP.NET pipeline, IIS does not. This was causing a request for an image file or javascript file (or any other static resource) to close my NHibernate session before I was actually thinking it should close.
Thanks for the list of resources, I will certainly look into them.
If your object is lazy-init and no session is open, resolving the properties will fail.
Remember that lazy exceptions will most probably appear when you have some relationship with another entity that hasn't been initialized.
http://forum.springframework.org/showthread.php?t=13474
I would also recommend using something like the HTTP Module in Rhino Commons to manage your NHibernate Sessions.
You should use a shrinkwrapped package for dealing with this.
I like to use Autofac with ASP.NET/MVC integration. You simply ask the RequestContainer for an ISession whenever you need it and, because the ISession is IDisposable, the RequestContainer automatically knows to dispose of the ISession when the current request ends. Everything is taken care of for you.
use HttpModule if you need lazy loading. Inherit your class from it and then you'd have two methods you can override (can't remember their names). First one is called each time any page is requested. Open the session there and put the session in viewstate. The other method is called when page is posted back, close your session there.