[drmaa-wg] SGE, drmaa_job_ps and DRMAA sessions

[Rajic, Hrabri]

SHALL is a bit strong, so we have intentionally allowed room for a differentiation, i.e. quality implementations. 

    -Hrabri
 

-----Original Message-----
From: owner-drmaa-wg at ggf.org [mailto:owner-drmaa-wg at ggf.org] On Behalf Of Peter Troeger
Sent: Friday, March 04, 2005 3:57 PM
To: Tim Harsch
Cc: Áncor González Sosa; drmaa-wg at ggf.org
Subject: Re: [drmaa-wg] SGE, drmaa_job_ps and DRMAA sessions

Sorry for the late answer. I'm not a SGE expert, but DRMAA section 3.1.2 
is very clear about this:

"... Job Id's SHALL remain valid from one session to another. Job 
control routines SHOULD work
correctly if a job Id came from a previous DRMAA session, provided the 
current DRMAA session
knows how to resolve this job Id. The burden is on the user to match 
previous job Id's with
appropriate DRMAA sessions (i.e., DRMAA implementations). It is 
RECOMMENDED that
restartable applications make job Id's persistent in order to access the 
already submitted jobs."

In sum, you need to persist your job id's with an own mechanism. It 
SHOULD be allowed to re-use old job id's in a new session. This approach 
ensures that the DRMAA library is not enforced to do any kind of data 
storage.
If SGE works as described, than the "SHOULD" keyword from the 
specification is ignored. If this was intentional, then I would be 
interested in the reasons (Andreas ? Dan ?). I really agree to the 
argumentation of Tim, so maybe the "SHOULD" keyword has to be a "SHALL".

Regards,
Peter.


Tim Harsch schrieb:

>Ancor,
>    Someone who knows the spec better than I should probably confirm but I
>believe drmaa_job_ps is indeed only tracking the jobs submitted from within
>the session.  In my opinion, for drmaa_job_ps, it is indeed how the
>behaviour should be from a sort of object oriented perspective... however,
>that doesn't meand there shouldn't perhaps be a sessionless set of API
>functions designed for manipulating jobs on the grid as a whole.  I don't
>know if this has been discussed for DRMAA before or not.
>    I can see how this would be a problem for a set of CGIs, since each are
>a new process you'll not be able to maintain the drmaa_session accross
>processes.  I don't know if there is a way around it...
>    You might have to consider maintaining your job ids in a persistent
>store of your own and backtick calls to qsub, etc.  Its ugly in that you'll
>have the process overhead each time, but you'll get more of the SGE specific
>features that way.
>
>    Perhaps the group can help tell us if there is a way to set up a
>persistent DRMAA session?
>
>    Wouldn't this problem also be a problem for Globus?  At one of the
>conferences they were saying that Globus would (in the future) perhaps use
>DRMAA as the tie in to the DRM, seems like without persistent sessions this
>might be a bit difficult in practice.
>
>HTH,
>Tim
>
>----- Original Message ----- 
>From: "Áncor González Sosa" <ancorgs at softhome.net>
>To: <drmaa-wg at ggf.org>
>Sent: Wednesday, March 02, 2005 3:34 PM
>Subject: [drmaa-wg] SGE, drmaa_job_ps and DRMAA sessions
>
>
>I'm developing a webmin module for submiting jobs and fetching the results
>in
>a cluster with Sun Grid Engine 6.0u1. I'm using Scheduler::DRMAAc, the Perl
>wrapper of the C binding of the DRMAA specification.
>
>My problem is that drmaa_job_ps() only works for jobs that have been
>submited
>in the current DRMAA session. Is this the expected behavior in any DRMAA
>implementation or is a feature/bug of SGE 6? I'm not sure, even after
>reading
>the DRMAA 1.0 specification paper. If it is the normal behavior of a DRMAA
>system, I find DRMAA really useless for "unattended" execution.
>
>Greetings
>  
>