Scheduled Jobs & clustering - Multi/Single cluster node execution?

[ajmas]

Could you tell me whether the scheduled jobs provided with Alfresco are cluster aware, such that when triggered will only run on one node at a time?

Additionally, how do I define triggered jobs (possibly with examples), that:
- run on one node of the cluster, when triggered
- run on all nodes, when triggered

I am looking at the documentation and the Spring configuration and it is not clear what the default behaviour is and how it may vary between specified jobs.

[mrogers]

Jobs run on all nodes.   Typically they will use the JobLock service if its important that only a single instance of a job runs at a time.

[ajmas]

I was looking at nodeServiceCleanupTrigger and contentStoreCleanerTrigger, as jobs that I imagine shouldn't be running in parallel, but I couldn't see evidence of JobLock Service being used here, when looking via Spring config and source code?

Can you provide some clarification here? For contentStoreCleanerTrigger, does it run in parallel once triggered, in a clustered environment, and if so, does that not potentially cause issues, given the work it is doing? If it isn't, where is the JobLock service being used, since I am probably not looking in the right place?

[mrogers]

You are looking at the trigger.  

If you look at the Job implementation e.g. ContentStoreCleanupJob you will see the locking.  

Well I do on HEAD/trunk!  

It may not be there on 4.2.    Can't remember when job locking went in.

[mrogers]

I've just checked.   4.2 does not appear to have job locking.  

Well it does have the job lock service,  but it doesn't look like its applied to the content store cleaner in that version.

[ajmas]

Thank you. I see it in 4.2:

https://github.com/Alfresco/community-edition/blob/V4.2a/root/projects/repository/source/java/org/al...
https://github.com/Alfresco/community-edition/blob/V4.2a/root/projects/repository/source/java/org/al...

Looks like it went in early, around version 2.2.

Looking at the code it makes be wonder whether it would make sense to have an AbstractLockableJob, that could then be extended. I say this based on what seems to be code duplication and clarification by extension that the Job is lockable?

[mrogers]

Perhaps…   

I'd also like to change the way jobs are scheduled and configured.