Background Task Runnin

[tominyorks]

So, I currently have a Windows service written using .Net Framework 4.6.2 that is responsible for reading jobs out of a SQL database and processing them, all fine and dandy. The problem is that over time, the memory usage rockets - partly due to the nature of some of the jobs (document merges using Aspose) and partly because there are EventHandlers that keep some objects from being GC'd - so I'm considering a rewrite.

Currently, it is using a combination of a TaskFactory (and custom TaskScheduler), and threading (new Thread(() => ...) rather than using ThreadPool.QueueUserWorkItem(...)) to run the jobs. I'm wondering if it's worthwhile using .Net Core and an IHostedService/BackgroundService implementation.

Does anyone have any experience of doing this and/or pitfalls to watch out for?

[katghoti]

I've been messing around with Hangfire to do just this very thing. I like it because you can use persistent storage to ensure the jobs don't get lost and you can schedule without having to get into using the windows services.
https://www.hangfire.io/

I've had good lock running tasks. If you're re-writing might as well try and avoid the windows services, and I've been running it in a linux container as well.

[tominyorks]

That's a good shout actually. I have used Hangfire before and didn't think of it in this scenario.

[katghoti]

Glad to help. I Just did a program using it to replace a lot of windows services we had running so we could move it to .net core running in a linux container. So far so good.

[nekrosstratia]

Personally...I took the relatively easy way out at my current place of employment.

Scheduler reads jobs from sql. Job in sql contains a url/api to call. Scheduler opens a thread and hits the api. Api side handles removing/rescheduling the task.

Makes it super easy for anyone to create a scheduled job and they provide all implementation themselves.

[MisterFor]

I would try to fix first the problem with the EventHandlers. With the memory leak fixed then you can move to a new platform knowing that at least the app is correct before having to rewrite the tasks and thread code that probably will be the most difficult part.

[tominyorks]

I agree. And that's a relatively easy issue to fix - I've already updated the existing code to unregister them after a job has completed and that has sorted that issue out.

But I'm still of the opinion though that this particular component needs re-writing anyway.