Break Hangfire Server out into separate process (do not run under IIS process)

[mgmccarthy]

@tonysurma please assign to me

The code for doing this is very simple, but the later item is to be done on the deployment side of things. We have to:

• update the build script to deploy a separate project, as this project will not be part of the web project
• research the best way to run this process in Azure. WebJobs? Something else? I don't enough about Azure yet to answer this question

I'm fine with the code changes. If any one out there knows how to run windows services/processes on Azure, I'd love to hear from you.

[dpaquette]

Where does AllReady use Hangfire?

We are already using WebJobs in the project so that would probably be a good choice.

[mgmccarthy]

In the code I'm writing for PR #1111 and Issues #1032 and #1084. I dont' know a lot about WebJobs, but they seem like something that is optimized for recurring tasks.. in both of those Issues, we're dealing with scheduling a task based on when a notification is published RequestsAssignedToIntinerary) to sms each Requestor 7 days from that date at noon.

Since I know very little about WebJobs, them maybe that is the solution here. I met with @MisterJames last Friday and we talked through the Issues as well as how we would use hangfire to schedule the messages going out to the requstors as the date of the request nears and the requestors have not confirmed the request via sms.

[dpaquette]

Ah, so this is new stuff. I was trying to figure out where Hangfire was in the app now.

@MisterJames is a WebJobs expert so he's the guy to talk to ;-)

[tonysurma]

I think we are good here as is or do we need to still break out @mgmccarthy @MisterJames ?

[mgmccarthy]

@tonysurma, we are still good here... if you want, you could throw this issue onto the technical backlog so we could pick it up later if we needed to...

"best practice" for Hangfire is to run the Hangfire server in a separate process (not under IIS), but for our initial launch, I think we should stick with the defaults. If performance becomes and issue, we can execute the code to fix this issue.

[tonysurma]

OK it's in backlog. Thx

[EmilyLuijbregts]

@tonysurma - are we OK to close this issue? or should it remain Open?

[mgmccarthy]

@MisterJames @dpaquette @dpaquette

FYI, after digging into WebJobs a bit more, it seems that Hangfire and WebJobs suffer from the same problem, they both run continuously in the background taking resources away from the web server (IIS/Azure app services)...

in order to move away from that model, it looks like Azure Functions are the way to go, as they "live" in their own app services when you create one or more...

that being the case, I'm not too sure how easy the transition would be for our existing two functions (ProcessSmsQueueMessage and ProcessEmailQueueMessage) that are running under a WebJob to become full fledged Azure Functions (aka, serverless) to offload the resource allocation from the other app service (aka, web server)...

but, it might be worth looking into, especially if we want to embrace asynchronicity in the form of sending messages to azure queues instead of using Hangfire's Enqueue method.

Thanks