More granular control of DisallowConcurrentExecution

[deanmarcussen]

What is the correct approach to allow more fine grained control of the DisallowConcurrentExecution functionality.

I know we know have access to setting the property on the JobBuilder which is useful, however I think I need to go a little more queue like.

Our scenario is hosted in OrchardCore, so we have a requirement to reduce the number of jobs that can run as a whole (which I can control with thread config I believe), but then I need to limit the number of jobs that are running on a particular shell/ tenant.

This is largely because all our jobs execute as a single job type, which run OrchardCore workflows, which may be of very different types, and talk to various apis which are sometimes limited. e.g. one workflow may need to be singular across the host as a whole, another maybe singular across that tenant, and yet another may be limited to perhaps 10 running across the host at a time.

I can make queries before scheduling the job (most are simple execute now triggers), but on some longer running cron jobs I would like to look to more of a window rule. (i.e. it should run between 4-5UTC, and spread some load between all the other jobs running around that time), so it would be preferable to adjust it's schedule, or whether it can execute at execution time, rather than at scheduling time.

I've been looking at the ITriggerListener and VetoJobExecution and wondering if that might be the best approach.

If, for example, I make the queries to fit the rules I'm defining in the VetoJobExecution method, and then if veto'ing it, reschedule it for x minutes in the future.

I am assuming that return true from VetoJobExecution will stop the trigger completely, and I would have to manually re trigger the job.

Has anyone else faced anything similar?

[lahma]

Having DisallowConcurrentJobExecution for a type guides the job key locking. So would it be somehow sufficient (or otherwise better) if you'd register such jobs per tenant/shell so that the job key (group?) would include context as discriminator?

Say these jobs sharing same type could be running at the same time but not individually at the same time would be (Group: "tenant-A", Name: "IndexManagement") and (Group: "tenant-B", Name: "IndexManagement") .

[deanmarcussen]

ok, great, I didn't realise that worked as a discriminator, was under the impression it was solely type based.
That's cool, I think I can probably work with that, to achieve what we need.

Thanks