Calculating contingency would seem to be a sensible idea - although probably not often done since I'm pretty sure it would require Monte Carlo calculations of uncertainties in schedule and budget, particularly if the schedule is "structurally stochastic" [see D. Rumsfield on "Unknown Unknowns"].
Bruce B. On Fri, Apr 19, 2013 at 8:55 PM, Chris A. Mattmann (JIRA) <j...@apache.org>wrote: > Chris A. Mattmann created OODT-602: > -------------------------------------- > > Summary: Load not settable for WorkflowTaskJobs in > IterativeWorkflowProcessThread > Key: OODT-602 > URL: https://issues.apache.org/jira/browse/OODT-602 > Project: OODT > Issue Type: Bug > Components: workflow manager > Reporter: Chris A. Mattmann > Assignee: Chris A. Mattmann > Priority: Critical > Fix For: 0.6 > > > Currently in IterativeWorkflowProcessorThread, this code block > automatically sets Load Value to 2 and doesn't allow override: > > {code:java} > if (rClient != null) { > // build up the Job > // and the Job Input > Job taskJob = new Job(); > taskJob.setName(task.getTaskId()); > taskJob > > .setJobInstanceClassName("org.apache.oodt.cas.workflow.structs.TaskJob"); > taskJob > > .setJobInputClassName("org.apache.oodt.cas.workflow.structs.TaskJobInput"); > taskJob.setLoadValue(new Integer(2)); > taskJob > .setQueueName(task.getTaskConfig().getProperty(QUEUE_NAME) != > null ? task > .getTaskConfig().getProperty(QUEUE_NAME) : > DEFAULT_QUEUE_NAME); > {code} > > I could have sworn this was configurable before, but I guess it wasn't. > I'm going to add a property called "Load" that can be set in tasks.xml on a > per WorkflowTask basis, that will propagate and allow override of the > resource manager job load when workflow manager is connecting to the > resource manager. > > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators > For more information on JIRA, see: http://www.atlassian.com/software/jira >
