Open cadilhac opened 1 year ago
Oh, it seems that this is simply because the cancellationToken requests a cancellation that RavenJobStore.SetSchedulerState throws an exception when LoadAsync is called with the token. Maybe a solution would be to avoid using this token in some terminal states like Paused and Shutdown?
The problem is that we need to cancel ongoing requests. Assume that you want to stop, and then you use another cancellation token, but the requests hangs, what do you do then?
The problem is that we need to cancel ongoing requests.
In the case of my server shutdown, my intent is not to stop instantly. The intent is to let the ongoing jobs finish their tasks or interrupt them gracefully (when Quartz is configured that way). So Quartz is waiting for the jobs to finish but the RavenDb store on its side is more in a hurry to interrupt any databse operation.
Assume that you want to stop, and then you use another cancellation token, but the requests hangs, what do you do then?
Maybe use another token with a reasonable timeout? Otherwise, isn't it a problem also to leave the quartz entities in the database in an inconsistent state? (state of the scheduler for instance).
Would this be something that you can provide a PR for?
I use this package with an injected store thanks to UseRavenDbWithInjectedDocumentStore in an asp.net core 6 project. When shutting down, I get these traces:
It hangs there, then this is displayed:
Any idea @ayende ? Could it be that the access to the RavenDb database has closed first and that the RavenDb Quartz store can not communicate anymore? If yes, how to ensure that the db closes after quartz has done its things?