We have web application developed in .NET Core and is hosted on azure. We want to use HangFire for report scheduling.
Our application is multitenant so it will have load of its own, So I want to run these background processes into different server. HangFire has option of Placing Processing into Another Process as Using Console applications or Using Windows Services.
I have gone through HangFire Doc but there is no clear explanation of how this main application (which is .NET CORE) connects to this Console application?
https://docs.hangfire.io/en/latest/background-processing/placing-processing-into-another-process.html
I came across this question but still is not clear to me
How to run Hangfire as a separate process from the main web application?
Your AspNet .Net Core application (the hangfire client) will not communicate directly with the console application (the hangfire server).
Communication is done trhough the storage (the database) : client declares new tasks in the storage, and the server polls the storage (or is notified by the storage depending on the storage technology, like Redis) to execute the tasks.
You need to ensure communication of both client and server with the storage, but not between the client and the server.
Related
I'm currently working on a high-traffic legacy Hibernate (5.0) web application that relies heavily on L2 caching with ehcache. Let's say this web application currently also contains a thread pool that writes data. The tasks in this thread pool don't benefit of L2 caching but cause plenty of invalidations. Now we'd like to take this thread pool out of the legacy app and put it in its own Java process, ideally on a different server.
Would it be possible to configure Hibernate/Infinispan in a way that the new task process doesn't have an L2 cache (or one with no actual capacity) but sends invalidations to the web app while at the same time the web app doesn't send any invalidations to the task process.
I am evaluating Hangfire for an upcoming ASP.net Core project that has several scheduled and reoccurring tasks that need to execute independently of users clicking on web pages. I know that HangFire can do this if the web application is started because a request has come in. I need to know whether or not HangFire can execute a scheduled task between being rebooted and the first web request coming in.
Example: Web server is rebooted at 11pm, and no web requests will come in to cause the web server to spin up until 5am the next morning. A scheduled task needs to be performed at 1AM. Will Hangfire execute this task even though the web application hasn't been started by an incoming request?
If it can, is there a certain setup I need to do to allow this?
Details, if needed:
We are going to be using Kestrel hosted in a windows service and sitting behind an NGINX reverse proxy. This setup could be modified if needed to make HangFire meet this requirement.
When running under IIS it would be a real problem, see Making ASP.NET application always running
But it should not be problem for ASP.NET CORE with kestrel, see
It is not necessary for ASP.NET Core, because application is exposed
by a console application that it already always on – there are no
timeouts, no suspends and other optimization techniques yet. All you
need to do is to use supervisor as written in the official docs for
Linux, or use Windows Service with automatic start time, when running
on Windows.
I'm building an app folowing DDD paterns with each AR having their events outbox saved to a permanent store.
That store gets polled by other parts interested in events.
Whole application is user oriented so the basic infrastructure is asp.net web api.
Now, i'd like to avoid having my domain artifacts spread across different processes/infrastructure options. For example, Azure Function that listens for event store & does logic upon events received.
It seems convenient to have web api & events consumer together in same container. Reason is that domain artifacts are deployed together with api & events consumer infrastructure.
I read that IHostedService might be one option for it as it can run as long running background process.
Question is, is IHostedService meant for this particular scenario of reacting to event outboxes? or are there some important drawbacks i'm missing and better infrastructural choices?
In general, I don't think there is anything wrong with using hosted service for running background workers.
I'm more sceptical about the "polling from other bounded contexts" part. I'd be at least concerned if that breaks the encapsulation of my contexts (similar to having "foreign" components read from a contexts persistence). But this might not be the case in your situation.
Anyways, in case you just want to guarantee that your events are reliably transmitted I would rather make sure that each component realizing a specific bounded context (e.g. microservice or component of a monolith) pushes these events somewhere interested consumer are able to pick them up.
So if it is about the reliable transmission of outgoing events I would suggest the transactional outbox pattern, maybe in combination with a publish-subscribe approach.
As you're on the .net stack the outbox feature of NServiceBus might be interesting for you.
Here's a link.) about implementing an IHostedService.
Indeed, IHostedService is a good way for long running process for your scenario by two methods.
It is important to note that the way you deploy your ASP.NET Core WebHost or .NET Host might impact the final solution. For instance, if you deploy your WebHost on IIS or a regular Azure App Service, your host can be shut down because of app pool recycles. But if you are deploying your host as a container into an orchestrator like Kubernetes, you can control the assured number of live instances of your host. In addition, you could consider other approaches in the cloud especially made for these scenarios, like Azure Functions. Finally, if you need the service to be running all the time and are deploying on a Windows Server you could use a Windows Service.
But even for a WebHost deployed into an app pool, there are scenarios like repopulating or flushing application's in-memory cache that would be still applicable.
The IHostedService interface provides a convenient way to start background tasks in an ASP.NET Core web application (in .NET Core 2.0 and later versions) or in any process/host (starting in .NET Core 2.1 with IHost). Its main benefit is the opportunity you get with the graceful cancellation to clean-up the code of your background tasks when the host itself is shutting down.
Is it possible to run an IHostedService on only one instance of a scaled out Azure App Service in ASP.NET Core? Or would the solution be to run this IHostedService in its own app service with one instance?
I have a BackgroundService that runs once a day and sends out reports via email. This service will run twice a day at the same time when my App Service is scaled out to 2 instances, resulting in two identical emails being sent.
How can I solve this problem?
It's better to break out things into separate apps, and that's the case here as well. If you only want one instance of your hosted service, you should break it out into a separate project and deploy one instance of that. If you deploy it inside your app, there will be an instance per instance of your app; there's no way around that, refer to this thread.
With Hosted Services, there is an instance running of that hosted service for every deployment of your website which can be an issue if you only want one instance of that “process” running at anytime. You can program around this by creating your own locking mechanism, but obviously webjobs gets this out of the box. So you can use webjob running as a singleton to achieve what you want. Refer to the article about Hosted Services In ASP.NET Core.
I have a simple solution with 3 projects:
Asp.Net MVC4 Web app - the main website
Console App - task runner
Console App - task runner
I wish to use MassTrasnsit to serve as a queue so that actions on the website (like send email) do not block the website, instead being published to the queue and taken care by the task runners.
My question is: Where should I initialize the queue, the web app, one of the task runners or create a separate console app for that?
ps. The console apps will be windows services when running on production servers.
As creating the queue is a one-off operation and you will probably want to tweak the default permissions, it would be best to create the queue in advance using a separate console app. Note that the publisher (the web app) and the consumers (the task runners) need a queue each, and that if they are on different servers then you will need to create the queues on each server.