I am having issue where when I trigger a hangfire task it doesn't process. It shows as fetched but not queued.
If I fully delete the hangfire schema and restart my application then I am able to run the task to completion but then subsequent triggered tasks go into the same fetched state.
If I look in succeeded then there is a count for a succeeded task but nothing shows:
The code itself executes fine (on first attempt after schema built). It looks like some error is happening on task completion but I see no error in the logs.
I am using Hangfire.PostgreSQL provider.
How can I fix/debug this?
Related
I have a recurring job, it works perfectly first time, but after the next execution, it gives ERROR. However, there isn't any exception or error in my GetPendingTrips() method.
Can some guide me what is the issue here in next attempt of recurring job?
RecurringJob.AddOrUpdate<ITripManager>(nameof(ITripManager), job => job.GetPendingTrips(), Cron.Minutely);
I have realized that Hangfire will not work continuously on background in IIS server, it will immediately stop the recurring job when there isn't any activity on the server. So in order to run the recurring job you need to do the following steps as mentioned in this article.
https://docs.hangfire.io/en/latest/deployment-to-production/making-aspnet-app-always-running.html
Can someone of you help me, how to make the following service selected in the image get into wait mode after starting the server.
Please let me know if developer trace is required to be posted for resolving this issue.
that particular process is a BATCH process, a process that runs scheduled background tasks (maintained by transaction SM36/SM37). If the process is busy right after starting the server, that means there were scheduled tasks with status released waiting for execution, and as soon as the server was up, it started those tasks.
If you want to make sure the system doesn't immediately start released background tasks, you'll have to set the status back to scheduled (which, thanks to a bit of weird translation, means they won't be executed because they are not released).
if you want to start the server without having a chance to first change the job status in SM37, you would either have to reset the status on database level (likely not officially supported by SAP) or first start the server without any BATCH processes (which would give you a number of great big warning messages upon login) and change the job status before then restarting the server with the BATCH processes. You can set the number of processes for each type in the profile of your instance (parameter rdisp/wp_no_btc).
We are running hangfire single threaded using BackgroundJobServerOptions.WorkerCount = 1 (because we have a requiement for ordered processing).
Most of the time this is no problem, but occasionally a job gets stuck for entirely expected reasons (eg, the actual code it is running goes into an infintite loop), but because we are running single threaded this prevents other jobs in the queue from starting.
In order to try and work around this, we delete the job, but then it stays on the queue, blocking any other job from starting:
The only way I have found to resolve this is to drop and recreate the hangfire DB which is obviously not great.
Why does deleting a running job in hangfire not also remove it from the queue? Is this weird delete behavior a bug which to be fixed in a later version, or is this behavior by design because we're running single threaded?
If this is by design then how do you cancel a processing job in a way which removes it from the queue?
Well it seems that this behavior is by design.
If the IIS app pool worker is recycled, Hangfire will start processing the next task immediately. However, without this restart Hangfire will "hang" indefinitely.
An issue was raised on github about this, however it has not been solved yet:
https://github.com/HangfireIO/Hangfire/issues/80
With no way to cancel or manually "fail" a job, this makes hangfire a lot less useful in a single threaded scenario.
Update: this has been partially or fully addressed in some later version of Hangfire.
I use hangfire to run recurring jobs.
My job get current data from the database, perform an action and leave a trace on records processed. If a job didn't run this minute - I have no need to run it twice the next minute.
Somehow I got my recurring jobs (1 minute cycle) queued by their thousands and never executed. When I restarted my IIS it tried to execute them all at once and clog the DB.
Besides than fixing the problem of no execution, is there a way to stop them from queuing up?
If you want to disable retry of failed job simply decorate your method with an AutomaticRetryAttribute and set Attempts to 0
See https://github.com/HangfireIO/Hangfire/blob/master/src/Hangfire.Core/AutomaticRetryAttribute.cs for more details
I am using SQL Server 2008 and I am writing a SQL Server Agent Job. In my Job, there are 3 steps and in each step I will execute a store procedure. I noticed that in default Notification setting, it write information to Windows event log only when it fails.
My question is, any easy solutions to write both success and fail information of each step to windows event log or somewhere to easily monitored? My job runs daily and I need the information for both success and fail to ensure my job runs.
thanks in advance,
George
The Notifications in the job properties also allows you to pick an action when the job succeeds! That button to the right is a dropdown, really - you can pick various outcomes, e.g. write to event log when it fails, and send an e-mail when it succeeds.
If you choose the "If job completes" option, I believe the action (write to event log, send e-mail etc.) will be triggered in both cases - success and failure.
Marc
PS: maybe this here helps?
http://msdn.microsoft.com/en-us/library/ms191130.aspx
If you want to notify an operator by e-mail, check E-mail, select an operator from the list, and then select one of the following:
* When the job succeeds to notify the operator when the job completes successfully.
* When the job fails to notify the operator when the job completes unsuccessfully.
* When the job completes to notify the operator regardless of completion status.