Hi Chris, Quoting [Christopher Smith] (Mar 06 2006):
FWIW
I see the JobService as being closely coupled to the resource manager, such that the constructor of the JobService could take the address of an RM endpoint.
I'm also not sure of the usefulness of having separate createJob and run methods, rather than submitJob ... and I can't recall the conversations that lead to the distinction. :-)
The main reason is the required ability to handle large bulks of jobs: saga::task_container tc; for ( int i = 0; i < 100000; i++ ) { saga::job j = js.create_job (description); // remember: job implements task tc.add_task (j); } // ran these jobs as bulk: tc.run ();
I do believe that jobs started with runJob are still "jobs" and should be added to indices. runJob is just a shortcut method (we had lots of discussions about whether to add it or not).
Right, run_job is just a shortcut, avoiding the job_description altogether. Cheers, Andre.
-- Chris
On 3/3/06 03:35, "Graeme Pound" <G.E.POUND@soton.ac.uk> wrote:
Hi,
I have some comments on the job section of the Strawman API (revision 1.4).
Thanks Graeme
-3.37 I do not understand the purpose of job_service.get_self() which returns a Job object.
-3.38 I like the removal of the JobInfo and JobExitStatus objects from the API, and adding this information as attributes to Job. This streamlines the API, the concept of read only attributes also makes sense [to me] within the context of the Job object.
-3.39 I like the simplification of the job_state enumeration. NB This is called 'state' in the SIDL and should be corrected to 'job_state'.
-3.41 The separation of the JobService.submitJob() method into two methods JobService.createJob() [create the job object] and Job.run() [start the job] has not been seamless and there are several of conceptual and practical problems. This needs to be fine-tuned further. On many [all?] resource managers there is no separation between submitting a job to the resource manager and manually starting the job, this raises the following problem: - Job objects are identified via the job_id which is described as the "job identifier as returned by the resource manager". Unfortunately since this information will only be available upon submission of the job (via Job.run()) this breaks the methods JobService.list() and JobService.getJob(). It is now impossible to manage an index of Job objects within JobService based upon the job ID. - What is the conceptual relationship between the JobService and the resource manager? At present this is a little confused in a couple of ways. #1 Should there be a one to one relationship between JobService instances and resource managers; i.e. should the resource manager endpoint be specified in the JobService constructor (or otherwise as an argument to JobService.createJob())? #2 The term JobService implies a close relationship to the resource manager. Previously JobService.submitJob() corresponded to communication with the resource manager. Now JobService.createJob() corresponds to the creation of instances of the Job class the JobService is acting as a factory. It may beneficial to rename JobService to JobFactory to clarify the relationship.
-3.42 Should Job objects created by runJob() be added to the index managed by the JobService? Or in other terms, should JobService.runJob() be a Java 'static' method?
-- "So much time, so little to do..." -- Garfield