nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Wait for job execution

cdoloriert

Hi,

I'm initiating a workflow from the command line using the iwjobc -i $workflowfile while looping through a dir that contains workflowfiles. It works fine the first time it goes, but the second time it fails due that two jobs want to run simulataneaosly. I think I need to tell the program to wait until the previous workflow is done.

Do you know any CLT to execute if the previous one is still running?
Maybe something like wait()?
What about iwcallback?
Any suggestions?

Thanks in advance.

Find more posts tagged with

Comments

Adam Stoller

Hi,

I'm initiating a workflow from the command line using the iwjobc -i $workflowfile while looping through a dir that contains workflowfiles. It works fine the first time it goes, but the second time it fails due that two jobs want to run simulataneaosly. I think I need to tell the program to wait until the previous workflow is done.

Do you know any CLT to execute if the previous one is still running?
Maybe something like wait()?
What about iwcallback?
Any suggestions?

Thanks in advance.

When you say $workflowfile - I assume you mean jobspec.xml - right?

I don't know of any aspect of workflows that would prevent you running two instances of the same workflow at the same time. I suppose it is possible with job specs - I'm not sure what algorithm iwjobc uses to prepare and monitor (if it does?) the process it spawns - but theoretically, each time you run iwjobc you should get a new jobid, which the '-i' flag should then be able to instantiate.

Perhaps there's some othe issue? If you count to 3 between running the command - do you still have the same problem?

Jamik

When you say $workflowfile - I assume you mean jobspec.xml - right?

I don't know of any aspect of workflows that would prevent you running two instances of the same workflow at the same time. I suppose it is possible with job specs - I'm not sure what algorithm iwjobc uses to prepare and monitor (if it does?) the process it spawns - but theoretically, each time you run iwjobc you should get a new jobid, which the '-i' flag should then be able to instantiate.

Perhaps there's some othe issue? If you count to 3 between running the command - do you still have the same problem?

He could also try something like (I'm assuming he's actually running a perl file due to the $workflowfile parameter):


my $jobcmd = `iwjobc $workflowfile`;
my $initjob = `iwinvokejob $jobcmd`;

Just to make sure that it's not an issue with iwjobc invoking the jobs (although I don't see why there would be an issue) and you could add some additional logging to grab the jobid to make sure there's no duplication going on for some strange reason.

This is what I have used for a custom script i have and it has no problems kicking off multiple jobs simultaneously. So I suspect either iwjobc -i or something in the workflow itself. My bet is on the "something else" is the culprit.

mdang

...but the second time it fails due that two jobs want to run simulataneaosly.

How would you know that was the cause? What was the exact error message?

--Michael

cdoloriert

How would you know that was the cause? What was the exact error message?

--Michael

It fails in OpenDeploy, the actual error is :



Wed May 13 12:04:02 2009 - COMMAND FOR SUBMIT TO STAGING: C:/Applications/Interwoven/TeamSite/bin/iwsubmit -x -u Y:\default\main\Integration\MonitorDotCom\WORKAREA\HQ\html\HQ_Home\USEnglish\testCD.html "Submitting file to STAGING"
Wed May 13 12:04:06 2009 - COMMAND FOR SUBMIT TO STAGING: C:/Applications/Interwoven/TeamSite/bin/iwsubmit -x -u Y:\default\main\Integration\MonitorDotCom\WORKAREA\HQ\images\aboutUs.jpg "Submitting file to STAGING"
Wed May 13 12:04:07 2009 - COMMAND FOR SUBMIT TO STAGING: C:/Applications/Interwoven/TeamSite/bin/iwsubmit -x -u Y:\default\main\Integration\MonitorDotCom\WORKAREA\HQ\templatedata\CommonContent\HQ_Home\data\USEnglish\testCD "Submitting file to STAGING"
Wed May 13 12:04:11 2009 - CLIENT_CMD: 'C:/Applications/Interwoven/OpenDeployNG\bin\iwodstart   Monitor/monitor_deploy -k area="Y:/default/main/Integration/MonitorDotCom/WORKAREA/HQ" -k targetArea="D:/TSReviewWebSites/MonitorDotComInt" -k useNode="MonitorIntegration" -k defName="MonitorInt" -k filelist="C:/Applications/Interwoven/TeamSite/tmp/filelist.577063.577074.20090513-120400.txt" -exttaskid 577074'
Wed May 13 12:04:12 2009 - 
** Results =  Locating OpenDeploy service.
 OpenDeploy server host: localhost, RMI registry port: 9173
 Got OpenDeploy service
***ERROR -  Starting deployment.
 Caught exception in getUser(). Details: null
 >>>>>-- Start deployment Monitor/monitor_deploy.
    iwodstart running in default synchronous mode.
    Need to wait for deployment to complete.
***ERROR -  Starting deployment.
  Reason from server: DEPLOYMENT_NOT_QUEUED
  Details     : Deployment monitor_deploy is already running. Request to start it now cannot be done. Rejecting request.

Wed May 13 12:04:12 2009 -  OpenDeploy Status Unknown. FAILED.
Wed May 13 12:04:12 2009 - odStatus = Completed with error
Wed May 13 12:04:12 2009 - callback (1) :  OpenDeploy Status Unknown. FAILED.

I increased the counter to 5 , the first one goes well, but the rest of them fail because they try OpenDeploy and it's already running. To be clear all the workflows deploy to same destination but for different content types.

The reason is Reason from server: DEPLOYMENT_NOT_QUEUED so can I make the workflow queable that way if OpenDeploy is running the workflow will wait instead of failing?

Any other suggestions?

Please let me know

Thanks in advance

ISCBorisB

Any other suggestions?

Sure... This is how you would normally do it: [post=141805]Concurrent Deployment Issue[/post]
You can use for example TaskID as a unique Deployment Instance

Adam Stoller

It fails in OpenDeploy, the actual error is :
...
The reason is Reason from server: DEPLOYMENT_NOT_QUEUED so can I make the workflow queable that way if OpenDeploy is running the workflow will wait instead of failing?

Boris has already provided a pointer, however I'd like to point out that the problem was not running workflows concurrently - it was running deployments concurrently - and that's a very different thing.

If you hard started the therad with the information you just posted, you would have been pointed in the right direction almost immediately.

cdoloriert

-inst made the trick.

Thanks