[SAGA-RG] Simple Job Management

[Andre Merzky]

Hi again, 

Quoting [Pascal Kleijer] (Dec 18 2006):
> 
> OK I let you digest the first part. If you need it I can bundle you the 
> code if you feel for some Java snack :p

*shiver* ;-)

>> [...]
>
> OK I didn't think about the Task constructor. I come from a school of 
> open mission critical software design where you need to mathematically 
> prove that at each stage of your application your system is stable. The 
> Unknown would sound strange.
> 
> >   saga::task = job_service.create_job <async> (&job, job_description);
> >   // job state is still 'Unknown' - cannot be run, yet
> 
> If I would implement this in Java the job would not be given in the args 
> list. But the task would return it after the task has finished setting 
> it up. The job is returned with another method call on the task and this 
> method returns a value *ONLY* when it has finished setting up. In that 
> case the Unknown state is always skipped for the user point of view. 
> Internally it might exists for a brief time.

Yes, I can see that this might make sense in Jave - it would look somewhat
unfamiliar in C/C++ though.  I guess the Java language binding would deviate
from the C++ binding then.  


> >>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?
> 
> Yes it does, but it would be better to make it clean in the 
> documentation that it might be redundant or that these values might be 
> different from what the JD actually has.

Ok, good point, that makes sense IMHO.


> >>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 ;-)
> 
> Yes I know. Actually returning an array is a possibility but not very 
> clean because you then need to do additional type casts. Since the 
> streams are available in the job, the Java binding will not return them.

Ok, again, that may make sense in the Java binding (we had multiple comments
from Java people about that exact point already).


> >>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.
> 
> I have found some more, see the public track page.

Great :-)

Thanks, Andre.

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