Make job scheduling workers AtoM instance specific
|Assignee:||Mike Gale||% Done:|
|Target version:||Release 2.2.0|
|Google Code Legacy ID:||Tested version:||2.2|
I didn't really think about this until we were going to deploy a test site with the job scheduler. Basically, what happens if there are multiple AtoM installs on a single machine that all use job scheduling? It doesn't make sense to share workers between them (they may have different versions of jobs, some might have jobs that are client specific, we don't want data sharing, etc.).
Currently, if we tried this any AtoM install's worker will accept any AtoM install's job requests. This will cause things to break, in some cases very badly. We need to make it so each worker process is tied to its AtoM install only.
#1 Updated by Mike Gale over 7 years ago
Unfortunately I'm not seeing an easy way to accomplish this. The only solution I can think of which is a bit hacky but would work, would be to broadcast abilities with the AtoM folder path pre-appended to the ability name. e.g. "/var/www/atom_a - arMyJob" & "/var/www/atom_b - arMyJob", and then that way only workers spawned from the appropriate AtoM installs will be able to 'accept' jobs for it.
Then, when the job is about to run, strip out the prefix here: https://github.com/artefactual/client-sfu-atom/blob/qa/2.2.x/vendor/net_gearman/Net/Gearman/Worker.php#L347