[SAGA-RG] Simple Job Management

[Andre Merzky]

Hi Pascal, 

below some answers/comments to the second part of your mail
- for the first part I need more time for digestion... :-)
Only so much: great that you attempt a SAGA implementation!!!

Quoting [Pascal Kleijer] (Dec 14 2006):
> 
> General comments and questions. Might be some meat for the public 
> comments as well:
> 
> Now we stumbled upon the state machine of the API. The "Unknown" and 
> "New" state are unclear to us. In our opinion when you create a job 
> either with the factory or directly with the constructor of the specific 
> incarnation, we enter the "New" state. The "Unknown" state is now 
> reserved for the very short time the object is instantiated but we 
> directly switch to "New" once the constructor is finished. The principle 
> in OO programming is to have a stable object once you finish 
> constructing it and calling method; if the constructor is not enough to 
> have a stable object you need a factory. So when you get an object back 
> it should be in a stable state, thus the "Unknown" state is superficial 
> in our opinion.

The new state is indeed supposed to reflect a successfull
job creation: the job was created by calling
job_service.create_job () synchronously.  The job instance
then has a job description, and methods like run() can be
called.

  saga::job j = job_service.create (job_description);
  // job is 'New' here, and can be run.

However, when the same methid has been called
_asynchronously_, the job instance remains uninitialized
until the async call returns:

  saga::job j;  
  // job state is 'Unknown' - cannot be run, yet

  saga::task = job_service.create_job <async> (&job, job_description);
  // job state is still 'Unknown' - cannot be run, yet

  task.wait ();
  // only now the job instance is initialized, and the state
  // changes to 'New' - run can be called now.

The state diagram contains the method calls which lead to
the different states - maybe that is not obvious enough...


> Some metrics or attributes or the Job are useless since they come 
> directly from the descriptor, Example: "ExecutionHosts", 
> "WorkingDirectory" or "CPUTimeLimit". Unless you consider that these 
> values might be different from the job description. Or if the job 
> description don't mention them the job can have this values assigned by 
> the back-end. Either case the API documentation should clarify this.

Well, these metrics are not useless, but potentially
redundant ;-)  as you say, the job_description might not
contain the respective values (only 'Executable' is required
in jd).  Also, you may not have started the job with a
job_description, but may have created the instane via
  
  list<string> ids = job_service.list_jobs ();
  saga::job    job = job_service.get_job (ids[0]);  

Also, things like CPUTimeLimit, pwd, or queue may get
changed by the backend.  Lastly, the metrics are
monitorable, so you can get notifictions on such changes.
That does not work with the job_description.

Does that make sense?


> The run_job from the service will not follow the API contract if 
> implemented. Only one parameter can be returned in java. Also the 
> streams are available thought the Job pattern.

Well, you can return an parameter array in Java - that is,
AFAIK, the java way to multiple return parameters?  

But, yes, streams are available anyway.  run_job() is a
convenience method anyway...  I am not sure how that should
be rendered in Java...  It'll probably be the single most
discussed call in the Java bindings ;-)


> In the document section 3.8.8 Examples the example at line 16 and 17 is 
> wrong (or the method is overwritten). There should be no string 
> argument. The host should be set in the descriptor.

Yes, indeed!  Thanks nice catch - I fixed it in CVS...

Cheers, Andre.

-- 
"So much time, so little to do..."  -- Garfield