I have an asp.net MVC web application that requires tasks to be scheduled. (A large chunk of functionality is scheduled)
I am using Quartz.net as my scheduler and am currently running it as a windows service. Clustering to handle load and performing resource intensive tasks out of peak hours
The problem I face is to be able to schedule all the required functionality I have to include everything in the scheduler service including all assemblies and most of the mvc base ( e.g using the MVC views to generate email reminder templates ) so the service becomes a duplication of the web application with lots of additional code to make it play nice. This is becoming a bit of a nightmare.
So I can?
1) Configure the scheduler to work within asp.Net MVC.
2) Use a Widows service that calls the required web page.
3) Use current service design.
my preference is probably #1 as this will resolve all of the above issues but the web app will get recycled/stopped if there is no activity for some time, This means that scheduled jobs may not be executed (only if there was some activity around the time when the job should be run).
Quartz.net setup in an asp.net website
Any thoughts/suggestions as to which is the best approach or any alternatives?
I would definitely avoid option 1. Your website should be request and response, nothing more.
If the action performed by your service is not 'long running' and can reasonably be performed as part of the request/response cycle of an HTTP request, then option 2 is reasonable. This should really be a web service rather than web page call, however (this is easier to do in OpenRasta which makes no distinction between web sites and web services).
If your scheduled action is intensive/long running then it ought to be done outside the website and your current architecture is probably ok. The replication of assemblies isn't really a problem (disk space is cheap).
Related
Context
I'm looking for a way to tell my users that one of the dependencies of my Asp.Net Core site is down and that therefore the site is currently not available. Preferably using an error page.
Asp.Net Core provides the Health Checks functionality to manage the logic of dependency health checking, but it only provides an endpoint meant for load-balancers.
There is also a kind of dashboard functionality available for the health checks but that is not meant as an error page for end users, it is aimed at administrators.
Why am I looking into this functionality?
I am using Azure Front Door. This product works as a load balancer. It can look at the health status endpoint provided by Asp.Net Core health checks and will take unhealthy backend nodes out of rotation.
However, it does not offer custom error pages and in the case that all backend nodes are down, it will assume that all nodes are healthy. One of the dependencies of my site is an external service that, if it is down, will be down for all instances of my site. It contains e.g. the user accounts that are needed for users to interact with my site. Therefore, I believe I need to implement an error page in the Asp.Net Core site that will show an error page when that external dependency is down.
Suggested solution
One of my ideas would be to have middleware that, when the site is degraded, always returns 503 Service Unavailable or throw an exception. The Asp.Net Core Status Page functionality could then turn that in an appropriate error page.
Question 1
Is this the best architecture? How have other people done this?
Question 2
What is the most practical way to access the current health status?
Technically it is possible to call the HealthCheckService.CheckHealthAsync(...) method directly, but awaiting that method takes some time (especially if one of the dependency services does not respond). Therefore it is not a good idea to make that blocking in the request pipeline.
I could use a Health Check Publisher to cache the health status by publishing it to some custom HealthStatusCache service, but it feels a bit like a workaround. Is this how other people would do it?
I have the following solution setup with 3 VS Projects all running in Azure:
-ASP.NET MVC site
-Azure Web Job
-C# Data Project
MVC site and Web Job have a reference to the Data Project. In the data project I have a static List<> "cache" when keeps some data in memory when called from my MVC site.
My Web Job is processing some data, then I'm attempting to clear that static cache in the Web Job itself. Is that not possible since the Web Job simply runs in its own instance when referencing the Data Project? This appears to be what I'm seeing.
One thought I had was to expose and end point on my MVC site which could be called from my Web Job to clear it (worst case)
Any other thoughts here?
No, one process cannot access to another one's classes and instances.
The best you can do is as you said create a mechanism to intercomunicate both processes, through an end point, a socket, a pipe or the one you best like.
I've got a stand alone WCF service providing REST services. As time goes on, I'm feeling like MS is going to reduce support for WCF and REST services, and I've already had to code in a bunch of hacks to get somethings working like CORS. Additionally, implementing https is another hack since it requires using OS functionality. (i.e. you have to install the certificate using an external application, which doesnt' make the service very self contained)
In anycase, I'm considering either a move to ASP.NET REST API and OWIN, or Java/Spring. I wanted to first see what it would take to move to ASP.NET REST, since I figured that should take the smallest amount of work, but I haven't found any good examples.
There's a pretty straightforward example on the asp.net site.
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
setup a self-contained project i.e console app or windows service
initialise and setup you routes
create your Controller / API stubs
deploy
Regarding SSL, whether it's IIS or Apache you will have to configure it on the web server regardless.
I am trying to use New Relic's .NET Agent in my Web API but all requests are being shown as System.Web.Http.WebHost.HttpControllerHandler, which is exactly what the docs known issues section says
MVC 4 (Note: New Relic provides limited support for the ASP .NET Web API for MVC4. All Web API transactions will appear as
HttpControllerHandler, not as the name of the web API controller.)
I am looking for any workaround that results in a more human readable dashboard, Is there any configuration in my app or IIS that I could change to have a more meaningful metric in my dashboard? Or is there a way of implementing the API calls in order to change this behavior?
NewRelic has released an update to the .NET Agent which should solve your problem.
See: https://newrelic.com/docs/releases/dotnet. "Improved WebAPI support. You should now see Web Transactions grouped by [controller].[action] rather than all WebAPI transactions reporting as System.Web.Http.WebHost.HttpControllerHandler."
you may get some better results by setting transaction names via the API. But, until New Relic improves overall support for ASP.NET Web API, there isn't a way to arbitrarily stuff things into web transactions.
https://newrelic.com/docs/dotnet/the-net-agent-api
SetTransactionName()
Also, if you specify certain methods to trace, when things are slow and a transaction trace gets generated, you'll see these custom method tracers appear in the trace details tree view.
https://newrelic.com/docs/dotnet/CustomInstrumentation
This is quite an old post but I spent quite a bit of time looking into a similar issue and in my case these delays were only appearing during POST where http message had request content.
In the long run, this was due to network performance problems (mobile clients) and the POST was trying to read the body of the message which is taking a long time to transmit. The take away being that these delays while showing in the controller handler were actually just waiting for the request body to be transmitted.
I have 2 web forms applications written in c# asp.net. This is the kind of thing I need:
A user clicks a button in web app 1
Web app 1 needs to send some parameters to web app 2 and get a response
Web app 1 uses the response from web app 2 to finish processing the post-back
User is happy
So I guess I need to incorporate some kind of web service thing into my web applications? Please point me in the right direction.
Update:
I've done some more research and found that WCF seems to be a goer. I have used WCF once before (stumbled through it) but how do I use WCF inside a web application - or do I need to create another application just for WCF?
Inter-process communication is a pretty large topic and there are many ways to do it.
Some tings to consider are
Synchronous vs Asynchronous - What should be the behavior if the user clicks the button twice in quick succession?
What should happen if user clicks the button but the web app2 is down for a few minutes?
Authorization and security
Denial Of Service style attacks
For something of this nature I would be inclined to use something like a message-queue maybe managed by something like nservicebus it would be a very simple, yet robust solution. WCF is another option and so is MVC 4.0 web services.