I’m probably abusing the setup here, but I have implemented a job packaging system which I send to a single workstation that has multiple slaves. When those slaves are processing at the same time, it appears that the job submissions are getting corrupted. Jobs that should be getting submitted once, get submitted n times, taking the place of other jobs that don’t get submitted. I’ve made sure each submission script is using a unique pathname for the job and plugin info, but the problem remains.
Is there any risk involved in using deadline command from multiple processes concurrently on a single workstation (from individual slave sandboxes in fact).
There shouldn’t be any issue running multiple DLCs. They have their own connection pools and shouldn’t conflict with one another. Re-using job info files has burned me in the past in a similar way. How are you ensuring the paths are unique?
Well it was just the standard Nuke deadline submission script which I think creates a unique temp folder. I have doubled-down on this and add a uuid4 value to the filename.
The custom plugin that I’m using just opens a json txt file that’s passed to the slave as an auxillary file. In that json file are the instructions for generating new deadline jobs. What appears to be happening is the correct number of jobs are getting generated, but that the jobs themselves are randomly becoming duplicates of previous ones, rather than jobs with the correct properties (jobname, payload, etc).
Most likely it’s a logical fail on my part, but I’m struggling to figure out what I might be doing wrong, as as you say, each slave is it’s own environment and they shouldn’t interfere with each other…
Thanks again for your help.
Yeah, no problem. If I were you, I’d dump the plugin info and job info files before each submission to get some visibility.
Deadline itself using MongoDB ObjectIDs and we’ve never had collisions of data. I have submitted 30,000 jobs that were all exactly the same though. That was fun. 