How to not retry jobs after app pool crash / stop

question
1

Currently, when the app pool crashes or is actively stopped and there is jobs currently running, these jobs stay in status “processing”.

When app pool comes back up, the job gets into “processing” again on a new worker and is started over.

Is there any way to prevent this? I’d like the job to be marked as failed, when it was running and the app pool of IIS goes away.

We tried setting retries to 0 on the method and globally, but this didn’t help at all.

Thanks for your help!
Philipp

1 Like
2

That’s what it is has to be. I mean it must stay on processing state. If you are having problem with this flow; the problem is not on the flow, it’s on your code and logic.

Try to migrate your code to this flow. Probably using batches is gonna solve your problem :slight_smile: Dont make batch operations in one job. For example if u gonna sen 100 emails, create 100 different job. Dont create a loop in one job. If u do that u have to face with thoose challanges :slight_smile:

3

Our problem is / was a little different:

  • We do a single long running call (to an external library)
  • In some situations this library used all the available memory erroring out in an OutOfMemory exception
  • This killed the App Pool
  • The app pool would restart, the process restarts and kills the app pool again … and so on

I’m very well aware, that there are deeper problems which need to be fixed (more precisely which have been fixed already), but we want to prevent, that in future situations we run into this “endloss loop” again of hangfire processes killing the IIS app pool over and over again.

1 Like
4

We are facing similar problem, how did you resolve this issue? or is it still standing ?

1 Like
5

Looking for a solution for this as well. For a simple example, start a long running job (e.g. w/ Task.Delay), and then stop the parent process w/ CTRL+C. Starting the process back up automatically resumes / retries that job, even when using the AutomaticRetryAttribute Attempts = 0 global filter.

We’re looking for a way to conditionally disable this behavior for the same reason explained above: for failure cases where the same job just keeps getting run over and over with no ability to stop that behavior.