jamesmh
commented
5 years ago The "prevent overlap" feature only applies to jobs that are run within the scheduler.
Adding a ".Once()" method to the scheduler could work. But that means having to deploy the application whenever you want to run it? That doesn't sound like a great solution.
I'm thinking that introducing a new construct altogether would be better. Something like a new interface:
interface IPreventOverlap
{
string PreventOverlapKey() { get; }
}Implemented by an invocable, it could be used to simply tell that specific invocable that it will always prevent overlap (no need to specify when scheduling it either).
If queued, it would try to get a lock etc. (in the same way described below).
A potential fix (for now if it's critical...) is to manually try to lock the job using the same Mutex that the scheduler uses. You would inject IMutex from the DI container and call bool TryGetLock(string key, int timeoutMinutes) and void Release(string key)
// Wherever you are manually launching the job from...
IMutex mutex = this._mutex; // From DI
int timeoutInMinutes = 60; // This will release the key after 60 min in the event something bad happens.
string overlapKey = "MyPreventOverlapKey"; // Same key used in ".PreventOverlap()"
bool available = mutex.TryGetLock(overlapKey, timeoutInMinutes);
if(available)
{
try
{
await new MyInvocable().Invoke(); // run the job
}
finally
{
mutex.Release(overlapKey);
}
}For reference, in the scheduler, this logic is here
That being said, relying on the internals of Coravel is not a best practice lol.
I like the interface options as a potential new feature 😅
oltronix
renevdhoek
nicoletacristian
mnj
So lets say we have a moderately heavy job that imports something to our db every 20 minutes. Occasionally we are asked to run this manually because the 20 minutes wait is just to long, using Coravel we could then trigger this using the Queue, but if we're unlucky this would coincide with the scheduled run every twenty minutes, which would cause some issues in legacy exports we have. Can this overlap be detected and avoided?
As an alternative it would be nice if we could schedule a one off run of an invocable, like scheduler.Schedule().Once();
That way it could take the overlappingprotection into account and share the same thread as the regular execution.