That can sometimes be a good thing, if you want to...
# suitescript
s
That can sometimes be a good thing, if you want to ensure two instances of a script never run at the same time, which is sometimes needed. If you don’t want that restriction, I know some people here have mentioned even dynamically creating new deployments and starting them. Also, if you have pre-created a few deployments, you can just specify the script, and not the deployment, and NS will just choose an available deployment for you (assuming they aren’t all currently running or pending)
j
Also, if you have pre-created a few deployments, you can just specify the script, and not the deployment, and NS will just choose an available deployment for you (assuming they aren’t all currently running or pending)
this is handy. I’ll just make like…5 that are the same
to handle the rare case when it gets called back-to-back
b
although usually not an issue for low concurrency tasks, whatever logic netsuite uses to pick an available deployment is not thread-safe
you can still get the FAILED_TO_SUBMIT_JOB_REQUEST_1 error even if you dont specify a deployment and there are deployments available to run