-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trigger state "BLOCKED", never gets unblocked and job stalls out in Quartz .NET 3.8 #2202
Comments
I just ran into the same issue today and am trying to figure out how to recover the stalled job too. Just setting the TRIGGER_STATE back to WAITING wasn't enough - I saw |
OK, what worked for me to fix the stalled job was: DELETE FROM QRTZ_FIRED_TRIGGERS WHERE TRIGGER_NAME = 'TriggerName';
UPDATE QRTZ_TRIGGERS SET TRIGGER_STATE = 'WAITING' WHERE JOB_NAME = 'JobName'; @xantari Did you try any of the releases between 3.5.0 and 3.8.0? |
Nope didn’t try those versions. Went back to 3.5 for now. |
We have a similar problem occur intermittently in 3.8, but the |
That might be #707, which I've run into too - I commented there but didn't get any response, but given the age of that issue, it might be worth opening a new issue if you think that's the problem you're having too. |
For what it's worth, we eventually started encountering the EDIT: We actually found our problem to be in CsvHelper. We switched from |
Describe the bug
TRIGGER_STATE in QRTZ_Triggers is shown as "BLOCKED". Job never resumes. How am I supposed to recover from a "BLOCKED" trigger?
Version used
Quartz .NET 3.8 - .NET Core 8.0
To Reproduce
Have no idea how it became blocked. It was processing a long list of data and just stalled out.
Expected behavior
Job should go back to Waiting status....
Additional context
From what I can tell, the job begin at 11:31 AM PST, ran for a very long time. It is a every 5 minute recurring schedule. The 11:31 AM PST job was still running at 11:35:01 AM when it tried to fire again and it tried to start again. Which is wierd, because [DisallowConcurrentExecution] is on the job. I think this is where it got deadlocked with itself.
Must not be monitoring the DisallowConcurrentExecution tag anymore I suspect.
Reverting back to 3.5.0 and will monitor the situation more.
The text was updated successfully, but these errors were encountered: