Simultaneous submissions....

Is there any fundamental reason we can’t do simultaneous submissions from 2 different 3dsmax sessions? It seem at the moment that the temporary files fight over each other. This might just be our own batch submitter but I thought I’d mention it here as it’s something that I think happens in the normal submitter too.

Indeed, there are a few odd race conditions. It’s funny you should mention this, as I’m just finalizing the functions to hand over for implementation into SMTD. There were some interesting performance improvements in this area as well.

Submissions in SMTD are supposed to be encapsulated in unique subfolders with date and time stamp in the name.
The function to call before setting up the submission’s JOB files, Max scene file etc. is

SMTDFunctions.createSubmissionFolderAndUpdatePaths()

When this is called, a new sub-folder of the submissions folder will be created, and all relevant paths will be updated:

SMTDPaths.submitSubFolder = theSubFolder SMTDPaths.SubmitInfoFile = theSubFolder + "max_submit_info.job" SMTDPaths.JobInfoFile = theSubFolder + "max_job_info.job" SMTDPaths.ResultFile = theSubFolder + "max_output.txt" SMTDPaths.BitmapList = theSubFolder + "max_sceneBitmaps.txt" SMTDPaths.RestoreTempMaxFile = theSubFolder + "max_backup_file.mx" SMTDPaths.SubmitOutput = theSubFolder + "submitOutput.txt" SMTDPaths.SubmitExitCode = theSubFolder + "submitExitCode.txt" SMTDPaths.ImsqVbscriptFile = theSubFolder + "copyImsq.py" SMTDPaths.DraftConfigFile = theSubFolder + "draft_tile_config.txt"

If you are using SMTDFunctions, just call this before starting a new job submission.

What could collide between multiple 3ds Max sessions is the resolving of Pools, Groups etc, as these functions do not use unique folders right now. We intend to move those to in-memory DotNet handling ASAP.

But what if two jobs gets submitted at exactly the same time?

Are you asking for an additional incremental number if a folder already exists?
Or I could check if the folder name already exists, and just loop until I find a name that does not…
I feel the chances for hitting the same submission time stamp are very very low, but if you really want me to, I can do that :slight_smile:

EDIT:

I just added a do… while (doesFileExist theSubFolder) loop around the name creation, before the makeDir() is called. Now calling the function twice from MAXScript listener always creates two folders with 1 second difference, in the past it produced the same folder. This should prevent parallel sessions from coming up with the same name.

Sounds logical :slight_smile:

I’ve finally found time to look into this. I’ve made some adjustments in our own submission code that we use to make sure no temp file fight one another but I’ve had some failed submissions when I try run two submission batches in two sessions of max at the same time.

The problem lies somewhere in here I guess as my return code is giving a fail. Do I just need to up the submission timeout setting? or is there some issues with C:\Program Files\Thinkbox\Deadline7\bin\deadlinecommandbg.exe that stops it submitting two jobs at the same time???

(still on Deadline 7.2 at the moment.)

[code]–This function calls the deadline executable with the supplied parameters and waits for a specified time in SECONDS for the execution to complete
–If the result is not returned in the given time, a #timeout result is returned.
fn waitForCommandToComplete params timeOutInSec paramIsFile:false dontWait:false =
(
local result = -2
deleteFile SMTDPaths.SubmitExitCode
deleteFile SMTDPaths.SubmitOutput

		if paramIsFile then
			ShellLaunch SMTDPaths.DeadlineBGExec params
		else
			ShellLaunch SMTDPaths.DeadlineBGExec (" -outputfiles \""+SMTDPaths.SubmitOutput+"\" \""+SMTDPaths.SubmitExitCode+"\" " + params)
		
		if dontWait do return #queued
		
		local startTimeStamp = timestamp()
		local ready = false
		while not ready do
		(
			sleep 0.15
			SMTDFunctions.AnimateLastSubmissionState()
			try(windows.processPostedMessages())catch()
			if doesFileExist SMTDPaths.SubmitExitCode do
			(
				local theFile = openFile SMTDPaths.SubmitExitCode
				try(result = readValue theFile)catch(result = -2)
				try(close theFile)catch()
				ready = true
			)	
			if timestamp() - startTimeStamp > timeOutInSec*1000 then 
			(
				result = -3
				ready = true
			)	
		)				
		return case result of
		(
			0: #success
			(-1): #failed
			(-2): #readerror
			(-3): #timeout
		)	
	),[/code]

To sidestep these issues, we ported to use .NET process and no external files in 8.0.0.69 as per release notes:

Sweet, I’ll get right on with testing that next week then!